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.

Re: Garmin gns530

Postby Hooray » Sun Jul 27, 2014 9:01 pm

ND: sounds good !

FYI: Several years ago, the Garmin guys allowed the FlightGear project to re-implement the whole instrument in FlightGear, see the devel list archives for details.

  • regarding those screen shots there's a free EXE download available from Garmin that simulates the device using the firmware of the real device IIRC, the so called "Garmin GNS trainer"
  • it's a subset of the device, including 2-3 integrated databases (AIRAC cycles, waypoints, navaids etc)
  • that is the reason why those EXE files are >= 100 MB in size
  • some functions are just stubs to look plausible (e.g. satellite status view)
  • those flight simulators addons (XP) etc will typically run that simulator, copy the image to memory and display it in FSX/XP and forward events accordingly
  • we used to have a discussion about this whole approach a while ago
  • so that is why the thing looks and "feels" so real: it's a subset of the firmware of the real device, running in the standalone EXE simulator (works fine under Linux/Wine, and then IPC is used to display/control the device): http://www8.garmin.com/support/download ... sp?id=3529
  • the XP forums have a lot of detail on the whole approach, or just see: http://ross-park.net/xgps/config/win_500w.html
  • regarding the ND: no, the idea is just to incrementally move useful stuff out of the ND into dedicated MapStructure layers - the compass rose, CDI etc could definitely be useful outside the ND context
  • Yeah, I am also horrible at Inkscape, but we have volunteers who are willing to help with such things, because they prefer that over writing hundreds of lines of code :D


We should be able to replicate most of the functionality easily by now - even though some features are more difficult, because we don't currently support ESRI shapefiles ...

PS: Here's the latest X-Plane status: http://developer.x-plane.com/2014/03/ne ... ane-10-30/
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

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

Yes, I do know the Garmin Trainer, I'm using it, in addition to the official manual, as a benchmark for my model. I didn't try wine, though, I run it on Windows 7 in a Virtual Machine. Good to know it will work fine in wine.

Volunteers? Where are volunteers? :D I have BoeingND.svg open in Inkscape on another virtual desktop, and I get frightened every time I pass over that desktop on my way to some other one!

The x-plane gps looks great. I never used x-plane, never even tried. But that definitely looks good. They have nice looking Airspace displays. Do we have some kind of airspace api in flightgear that will provide the information needed for "nearest airspace" pages and "close to airspace" popup warnings? Also, is there an airspace layer to the MapStructure?

Another (loosely related) question: Are the fixes in the nav database classified in some way? Like, high altitude enroute, low altitude enroute and procedures (star and sid related)? The nearest intersections list is really cluttered with the approach/departure waypoints, and I don't think I should usually display them there. In the map, also, it would be nice to only display procedure related fixes during actual procedures (approachs or departures), and otherwise only display enroute fixes. I don't care about the high-altitude jet routes versus low altitude airways that much, but filtering out the procedure fixes would definitely be nice.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Mon Jul 28, 2014 5:43 am

cbendele wrote in Sun Jul 27, 2014 10:00 pm:They have nice looking Airspace displays. Do we have some kind of airspace api in flightgear that will provide the information needed for "nearest airspace" pages and "close to airspace" popup warnings? Also, is there an airspace layer to the MapStructure?


not yet, but we're planning to add one sooner or later, some of the data we have already, it's just not exposed to Nasal yet - see:

viewtopic.php?f=6&t=21762&p=199446&hilit=#p199446
viewtopic.php?f=75&t=23041

That will involve using cppbind to expose some existing data structures to Nasal:

http://wiki.flightgear.org/Nasal/CppBind
http://wiki.flightgear.org/Canvas_MapStructure_Layers

(loosely related) question: Are the fixes in the nav database classified in some way? Like, high altitude enroute, low altitude enroute and procedures (star and sid related)? The nearest intersections list is really cluttered with the approach/departure waypoints, and I don't think I should usually display them there. In the map, also, it would be nice to only display procedure related fixes during actual procedures (approachs or departures), and otherwise only display enroute fixes. I don't care about the high-altitude jet routes versus low altitude airways that much, but filtering out the procedure fixes would definitely be nice.


I think Gijs raised the same question a while, at least his ND code has some comments along those lines - so I don't think there's any classification in place currently, keep in mind that the navdb is not very recent at all. But we can also use NaviGraph data - so it should be possible to enrich the data accordingly and update the SQL db. It mainly depends how responsive core developers are - the navdb is being maintained by one of the most active core devs (Zakalawe).

But even absent any support there, the MapStructure/ND side of things could even be purely driven by an alternate data source without too much work:

Subject: 777 EFB: initial feedback
Hooray wrote:Well, we've been talking about the lack of current navdata in FG recently. On the MapStructure side of things we really only need to encapsulate any NasalPositioned calls, to support arbitrary data - including even fetched (XML), or manually entered navaids/fixes. Such data could then be centrally served or based on NaviGraph. So we wouldn't have to touch any of the existing NavDB stuff to work around its limitations.

So I am thinking about moving all NasalPositioned queries in MapStructure into a "driver" hash, but maybe more in line with the aircraftpos.controller stuff that Philosopher developed, just specific to some kind of "NavaidSource".

That would allow us to easily work around such limitations, so that I-NEMO, Hyde, Gijs etc can easily use the latest data on their EFB/ND. The other motivation here is that I experimented with interactive layers, i.e. where objects could be visually placed on a map-these could be scenery objects, but also navaids. And once we move such assumptions out of the lcontroller files, we can trivially support other cool use-cases.


So depending on future progress, we could easily support other sources and ignore the oudated FG NavDB - if necessary.

Regarding your recent commits:
For the sake of intuitivity, I'd consider moving the included base class to the top of the file, and individual page groups next ?
And right, we can easily extend NavDisplay.new() to support a props.Node() too - feel free to make that change, see $FG_ROOT/Nasal/canvas/map/navdisplay.mfd - it's kinda messy actually, the whole new() vs. newMFD() separation, but it's getting increasingly cleaned up - and having different aircraft/use-cases is helping make it more generic :D
This is one of those things where working directly with a fgdata clone (e.g. via canvas-hackers) is probably a good idea to help clean up things across related efforts, such as the ND and MapStructure.

Besides, we should probably also change the MapStructure/ND code such that it can directly use an existing canvas, so that you don't have to use a separate canvas here.
We were exploring supporting that for the GPSMap196 anyway - it makes sense to directly deal with a group and apply clipping etc there - instead of having the hard-coded assumption that there'll always be a fixed-size canvas available. For the 196 that would be nice, because it supports multiple "map" views on a single screen.

Regarding the whole PageGroup structure, I think that's looking pretty good already - good job !
And even if you never consider to support the GNS430, I'd still suggest to keep the design sufficiently generic, so that others can have a go at it - even if that may not happen anytime soon, it will help modularize your code even more.

In the GPSMap196 we went a bit further and actually extracted device-agnostic APIs, so that other MFD-style instruments could be modeled on top of those APIs.
Currently, your code looks close enough actually - and once your mode/page handling is generalized some more, I'd kill off the old code and use your's :D
But as you can see in the GPSMap196 code, I'd consider adding a dedicated "Page Manager" class where all pages are registered, and where all event handling is taking place, and propagated to the active page via "mode" helpers.

To see for yourself, see: https://gitorious.org/fg/canvas-hackers ... /GPSmap196

However, that code uses a pretty weird approach in terms of button-handling via listeners - since then, Tom has updated Canvas to also support custom events, but that's not yet been integrated yet (F-JJTH is currently n/a). But the underlying idea -of having a dedicated PageManager- should scale better than most existing code:

https://gitorious.org/fg/canvas-hackers ... 96.nas#L62

It's a fairly simple helper class actually, but helps encapsulate mode-handling: https://gitorious.org/fg/canvas-hackers ... fd.nas#L47

Given your own work, you could probably borrow some ideas/concepts and easily make the old code obsolete, while allowing us to reuse your work in the GPSMap196 code.


EDIT: http://wiki.flightgear.org/Nasal_Variables
Code: Select all
diff --git a/GNS530.nas b/GNS530.nas
index 392908d..44883a6 100644
--- a/GNS530.nas
+++ b/GNS530.nas
@@ -156,7 +156,7 @@ var GNS530 = {
         buttons = ["Swap_C", "Swap_V", "CDI", "Range", "Enter",
                     "Radio_kHz", "Radio_kHz_rot", "Radio_MHz_rot",
                     "Cursor", "Cursor_rot", "Field_rot"];
-        foreach(p; buttons) {
+        foreach(var p; buttons) {
             gns.mynode.initNode("buttons/"~p, 0.0, "DOUBLE");
         };
 
@@ -177,7 +177,7 @@ var GNS530 = {
 
         ## general Annunciators
         ## ANNUNC window
-        screen = gns.mycanvas.createGroup();
+        var screen = gns.mycanvas.createGroup();
         screen.createChild("path")
             .moveTo(5,350).lineTo(160,350).lineTo(160,443).lineTo(5,443).close()
             .setColor(0.2,1,1).setColorFill(0, 0, 0).setStrokeLineWidth("2")
@@ -240,12 +240,12 @@ var GNS530 = {
     setup_comm_vloc : func(comm_num, nav_num) {
         var cv = {};
 
-        screen = me.mycanvas.createGroup();
+        var screen = me.mycanvas.createGroup();
 
         ## COMM and VLOC frequency windows
         conf = [    {label: "comm", text : "COM1", pos : 5},
                     {label: "vloc", text : "VLOC1", pos : 120}];
-        foreach(p; conf) {
+        foreach(var p; conf) {
             screen.createChild("path")
                 .moveTo(5, p.pos).lineTo(160, p.pos)
                 .lineTo(160, p.pos+110).lineTo(5, p.pos+110).close()
@@ -276,7 +276,7 @@ var GNS530 = {
         conf = [    { label : "vor_ident", text: "VOR", pos : 268 },
                     { label : "vor_radial", text: "RAD", pos : 300 },
                     { label : "vor_distance", text: "DIS", pos : 335 } ];
-        foreach(p; conf) {
+        foreach(var p; conf) {
              screen.createChild("text")
                 .setTranslation(15, p.pos-4).setAlignment("left-baseline")
                 .setFontSize(20).setColor(0.2,1,1).set("z-index", 1)
@@ -293,7 +293,7 @@ var GNS530 = {
                         com_stby : props.globals.initNode("instrumentation/comm["~comm_num~"]/frequencies/standby-mhz", 120.350, "DOUBLE"),
                         nav_freq : props.globals.initNode("instrumentation/nav["~nav_num~"]/frequencies/selected-mhz", 110.00, "DOUBLE"),
                         nav_stby : props.globals.initNode("instrumentation/nav["~nav_num~"]/frequencies/standby-mhz", 112.50, "DOUBLE"), };
-        foreach(k; keys(cv.nodes)) {
+        foreach(var k; keys(cv.nodes)) {
             setlistener(cv.nodes[k], func() { me.update_freq(); }, 0, 0);
         };
 
@@ -398,7 +398,7 @@ var create_nearest_list = func(type, maxentries) {
         if(type == "airport") {
             var info = airportinfo(entry.ident);
             entry.length = 0;
-            foreach(k; keys(info.runways)) {
+            foreach(var k; keys(info.runways)) {
                 if(info.runways[k].length > entry.length or
                         (info.runways[k].length == entry.length and info.runways[k].ils != nil)) {
                     entry.length = info.runways[k].length;
@@ -415,7 +415,7 @@ var create_nearest_list = func(type, maxentries) {
             entry.comm_id = "";
             entry.frequency = "        .  ";
             var comms = info.comms();
-            foreach(p; comms) {
+            foreach(var p; comms) {
                 if(substr(p.ident, 0, size(entry.name)) == entry.name)
                     p.ident = substr(p.ident, size(entry.name)+1);
                 append(entry.radio, {station : p.ident, frequency: sprintf("%3.2f", p.frequency)});
diff --git a/NAV.pagegroup.nas b/NAV.pagegroup.nas
index aa8012f..a199e9e 100644
--- a/NAV.pagegroup.nas
+++ b/NAV.pagegroup.nas
@@ -100,7 +100,7 @@ var NAV = {
             ## dep, dest, alt and enroute airfields, sorted by distance
             ## from current position
             stations = {"departure" : "Departure", "destination" : "Arrival", "alternate" : "Alternate"};
-            foreach(p; keys(stations)) {
+            foreach(var p; keys(stations)) {
                 var s = {ident : routemgr.getNode(p ~ "/airport", 1).getValue()};
                 if(s.ident != "" and s.ident != nil){
                     s.name = routemgr.getNode(p ~ "/name", 1).getValue();
@@ -109,7 +109,7 @@ var NAV = {
                     append(me.airports, s);
                 }
             }
-            foreach(p; me.airports) {
+            foreach(var p; me.airports) {
                 var info = airportinfo(p.ident);
                 if(size(info.comms()) > 0) {
                     var comms = info.comms();
diff --git a/PageGroup.nas b/PageGroup.nas
index a1e191f..297af4a 100644
--- a/PageGroup.nas
+++ b/PageGroup.nas
@@ -69,14 +69,14 @@ var PageGroup = {
                            {label: "right2", head_pos: 445, pos: 445, align: "center-baseline"},
                            {label: "right", head_pos: 615, pos: 620, align: "right-baseline"}];
         pg.header={};
-        foreach(p; pg.columns_conf) {
+        foreach(var p; pg.columns_conf) {
             pg.header[p.label] = pg.list.createChild("text")
                 .setTranslation(p.head_pos, 65).setAlignment(p.align)
                 .setFontSize(20).setColor(0.2,1,1).set("z-index", 1);
         };
         pg.entry=[{},{},{},{},{},{},{},{}];
-        forindex(i; pg.entry) {
-            foreach(p; pg.columns_conf) {
+        forindex(var i; pg.entry) {
+            foreach(var p; pg.columns_conf) {
                 pg.entry[i][p.label] = pg.list.createChild("text")
                     .setTranslation(p.pos, 103+(42*i)).setAlignment(p.align)
                     .setFontSize(28).setColor(0.2,1,0.2).setColorFill(0.2, 1, 0.2)
@@ -97,7 +97,7 @@ var PageGroup = {
                 .setTranslation(420, 475).setAlignment("right-baseline")
                 .setFontSize(30).setColor(1,1,1).set("z-index", 1);
             PageGroup.pnl.pageno_pictorial=[nil, nil, nil, nil, nil, nil, nil, nil];
-            forindex(i; PageGroup.pnl.pageno_pictorial) {
+            forindex(var i; PageGroup.pnl.pageno_pictorial) {
                 PageGroup.pnl.pageno_pictorial[i] = pageno_bar.createChild("path")
                 .moveTo(440+(20*i), 453).lineTo(450+(20*i), 453).lineTo(450+(20*i), 473).lineTo(440+(20*i), 473).close()
                 .setColor(0.2,1,1).setColorFill(0.2,0.2,1).setStrokeLineWidth(2).set("z-index", 1);
@@ -114,12 +114,12 @@ var PageGroup = {
         if(me.index > me.wintop + (viz - 1)) me.wintop = me.index - (viz - 1);
         if(me.wintop < 0) me.wintop = 0;
         var i = me.wintop;
-        foreach(p; me.columns_conf) {
+        foreach(var p; me.columns_conf) {
             me.header[p.label].setText(me.my_conf.header[p.label]);
         }
         while(i <= (me.wintop + (viz - 1))) {
-            forindex(l; me.my_conf.line) {
-                foreach(p; me.columns_conf) {
+            forindex(var l; me.my_conf.line) {
+                foreach(var p; me.columns_conf) {
                     var col = me.my_conf.line[l][p.label];
                     if(col == nil or col == "" or i >= size(me.my_list))
                         me.entry[i*me.my_conf.lines + l - (me.wintop * me.my_conf.lines)][p.label].hide();
@@ -166,7 +166,7 @@ var PageGroup = {
 
     update_pageno : func() {
         PageGroup.pnl.pageno_label.setText(me.group_name);
-        forindex(i; PageGroup.pnl.pageno_pictorial) {
+        forindex(var i; PageGroup.pnl.pageno_pictorial) {
             if (i < me.num_pages)
                 PageGroup.pnl.pageno_pictorial[i].setColor(0.2,1,1).setColorFill(0.2,0.2,1);
             else
Last edited by Hooray on Tue Jul 29, 2014 3:39 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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Mon Jul 28, 2014 1:27 pm

Thanks for the links, I looked at the PageManager and related code in the 196. I can definitely see the similarity, and I could well imagine doing something like this, and maybe joining the two solutions. Right now I could almost use the existing PageManager except for the assumption it makes that each page is svg based, which shouldn't be too difficult to eliminate.

Before I clean up the page handling and introduce a page manager, I'd like to get the whole list stuff out of my base PageGroup class. It doesn't really belong there, and once it is removed, I should already be halfway there when it comes to the page manager implementation.

I started a completely separate implementation of the list code last night based on the ScrollArea widget and referencing the nasal REPL console like you suggested. I finally threw everything away after a few hours because I somehow got entangled in the unfamiliar widget framework and the fuzzyness of my own intentions. The concept seems sound, though, and except for the dearth of documentation the widget framework seemed to do well. I'll probably give it another go tomorrow. I need a break from nasal, so today I'll probably work on the FDM some, and otherwise just fly around a bit with other people's aircraft models :D

Once I get the list thing sorted out I'll come back to the page manager stuff, and then I'll gladly discuss how we can make it so the same code base can be used for the 196.

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 » Mon Jul 28, 2014 1:36 pm

  • if you are going to adopt the whole PageManager idea, I'd suggest not to eliminate the SVG assumption, but just make it optional - like I said, I can foresee adopting the same approach in the GNS530 code, which would get rid of a lot of procedural 2D drawing code, while allowing non-coders to easily help style/maintain the corresponding SVG files - which would also pave the way for some kind of GNS430 eventually
  • I think several things you are doing in your GNS530 main class could/should be moved to some kind of "PageManager" that manages buttons and modes
  • Regarding the list drawing stuff (redraw_list), that is another low-hanging fruit that could be optimized, e.g. by adopting Tom's layouting system and creating a simple "table" widget - currently, your code is fairly massive here, because it's doing several things at once, including pseudo-layout management. Adding a "table" widget to $FG_ROOT/Nasal/canvas/gui/widgets should be fairly simple, and you could use it directly for the list stuff.
  • such a "table" widget could then also be added to a ScrollArea easily if needed
  • if you need help with widgets, feel free to create a new thread with more specific questions
  • the whole PageManager idea is mainly about moving huge conditionals into hashes, like hash['Cursor_dec'] = func() {}
  • another low-hanging fruit would be creating a Frequency class that manages initialization, updates, colors (inactive/active) etc in an encapsulated fashion
  • there are still a few hard-coded absolute properties in use which basically means that multiple instances would share certain state (mynode etc) - ideally, all device-specific properties would live in their own branch, and be relative
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Mon Jul 28, 2014 1:48 pm

lol. Eliminating an assumption for me is the same thing as making the need optional. Of course I'd like to also still support svg based pages, just not make them the only supported option.

I think the problem with the list thing I had last night was that I wasn't really clear about separating View from Controller (in a MVC design kind of way). I was still trying to keep the cursor control in the list class, which is rather complicated, because different pages need cursors in different fields. You don't just select a line, but a specific column in the line, and the selectable columns vary from situation to situation. Keeping all that logic inside the list View, like I'm still doing it now with the current implementation, and was trying again last night, is probably quite wonky, I realize now. Once I keep the C seperated from the V I don't think I'd have a problem to implement this either way.

If you mean the nested vbox and hbox stuff with Tom's layouting system, that's what I've been doing last night anyway. If you mean something else, please point me :D

Anyway, don't expect me to produce any nasal code today, I'm due a day off :D I'll plug in my Joystick and fly around over flightgear's beautiful scenery. I'll come back to the 530 tomorrow.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Mon Jul 28, 2014 2:36 pm

Yes, I was referring to the new canvas/layout engine for creating a "table" widget and placing list elements that way.
The way the page manager is implemented, it receives all events (buttons, switches etc) and each page can "subscribe" to certain kinds of events - that way, the page manager can decide if it wants to directly deal with the event, or "propagate" it to the corresponding page. Pages are very much like your PageGroup class, but use the notion of a "PageElement" that is typically SVG-based for now, but could just as well be callbacks to work with your existing code.

We've been trying to make the whole setup as loosely-coupled as possible, so that existing -and future- instruments can be easily expressed using the same 2-3 building blocks (buttons, modes, pages) - in the case of the 530, tabs could be expressed as "modes" probably. Another possibility would be making the whole thing recursive, we'll see.

Porting/updating the 196 should be fairly straightforward, because it's very much a stub still, i.e. mainly structural boilerplate - so it could greatly benefit from your work here
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Mon Jul 28, 2014 2:54 pm

Well, what I was doing regarding buttons with my PageGroups, all user input is first passed from the instrument class to the currently active page (group). That page then has a choice of either handling it itself and returning 1 or ignoring it and returning 0. Only if the active page group returned 0 will the instrument class even look at what happened, and decide whether there is some global action that should be taken. I didn't really design it that way consciously, but used a design I already had in my head because I used it a while ago for something completely unrelated (virtual device code inside a virtual machine monitor).

I also had the thought about recursion. Right now I didn't think there is enough code for a single page to warrant splitting up the page groups into separate classes for each page, and maybe model the page vs. group relation similarily as the page group vs. instrument relation. It would be a cleaner design, the current solution is a bit messy, but as long as a page group stays below 200 lines of code I personally still prefer that to having lots of house-keeping code for a cleaner design. Once we have actually decided on an abstraction and have a somewhat stable implementation for the page and button handling, then I might split out some pages to make it easier for others in case somebody else starts working / maintaining on the code. In that event I would prefer a recursive design, but If others object I wouldn't insist.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Mon Jul 28, 2014 3:04 pm

I agree - over time, this will probably evolve automatically, i.e. the more use-cases (like the GPSMap196) we have and support - we have quite a few efforts that could benefit from such a design, the 777 EFB ended up becoming much more complex than necessary because it is lacking the corresponding helpers and wrappers to encapsulate the concepts of 1) button/switch, 2) display mode and 3) pages.

Once you think about it, even a CDU or a ND/PFD could be implemented on top of the exact same framework - in the case of the PFD, it'd just be a single-page instrument normally.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby pommesschranke » Wed Sep 03, 2014 4:23 pm

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


So.. what exactly do you need to be done in Inkscape ?
A while ago I made a PFD and Michat made a lot of symbols for Maps/Charts/NDs
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: Garmin gns530

Postby pommesschranke » Tue Oct 14, 2014 1:56 pm

hmm.. seems like cbendele is not active here at the moment. :-(

Last visited:
Sun Aug 03, 2014 6:13 pm
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: Garmin gns530

Postby Michat » Tue Oct 14, 2014 3:47 pm

I'm here too.

And I have accomplished a set of windbarbs simbols that actually I am moving to the canvas ND inkscape document specification style (black background and so on) that I'll share soon in case if any of the developer can use it for their own FG project.

Cheers
User avatar
Michat
 
Posts: 976
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Garmin gns530

Postby tigert » Sun Nov 09, 2014 9:34 pm

Hey, I could also help with inkscape to develop the GNS530, we also have a 430 in our club's DA20, which is similar to in practice, just smaller screen.

It seems there have not been much going in the git repo the last months, but I think the '530 would be useful for a lot of GA aircraft, just like in real life.

For hte navdata, there seems to be at least the airbus for FG that uses the navigraph navdata, that could be one option. Or we could use openair format. Eurocontrol even has some kind of an API for navdata and notams etc, but I think the licensing is yet another "hey we are open (but our idea of open is not gpl-compatible)" case. One way would be to have optional updated navdata with fallback to the apt.dat. My understanding is that apt.dat is missing sid/star/airspace boundaries anyway, which are pretty essential on simulating the 530. I guess the navdata format could be anything, as long as there's a parser to read the stuff. I would assume there are going to be more collaborative efforts in this area also in the future.

Stumbled to this old page in google btw: http://www.avweb.com/news/reviews/18245 ... directed=1

//Tuomas (tigert on irc)
tigert
 
Posts: 106
Joined: Sat Nov 08, 2014 9:57 am

Re: Garmin gns530

Postby hjr70 » Wed Jan 14, 2015 4:01 pm

hjr70
 
Posts: 8
Joined: Wed Oct 09, 2013 3:21 pm

Re: Garmin gns530

Postby tigert » Sat Jan 17, 2015 10:46 am

Ok, this is interesting.

Ideally a free implementation would make senše, especially since who knows how those trainer programs work in the future, and we cannot ship them with fg easily either.

On the other hand, the trainer exe works great in Wine on linux, and we apparently support interfacing with real gns400/500 units via protocol support, wouldnt this be possible to include so that you could interface alternatively with real hardware and also the simulated application. And, would this perhaps work with the G1000 and gtn touchscreen navigator trainer programs also? In real life there are standard protocols avionics use to interact with each other.

Each trainer contains a hsi400.exe and they likely share most of their code with the real units, would be likely they have some virtual avionics bus, maybe that can be hooked into?

//T
tigert
 
Posts: 106
Joined: Sat Nov 08, 2014 9:57 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest