BRG 1 and BRG 2

[swatson999]

I think you are prisoner of a strange paradigm: that a BRG needle must be related to the aircraft's route.

That's not what they said, and it's not what the documentation says, either.  Go re-read the manual.

BRG indicators point to whatever the *input* device tells them to point to.  If it's the SV GPS, then that's the next waypoint.  If it's a NAV radio, then that's the VOR station.  If it's an ADF, then it's the NDB.

That's true if the GPS input device is SV itself, a Garmin whatever, or a King or Narco or Swizzle 500 or any other GPS box.

It's also true if it's an SL30, a King or Narco or you own hand-built VOR receiver.

And that is *exactly* how older RMIs worked, too.

Strange, because in classical instrument panels this is not the case: you can set a "needle" to whatever off-route navaids you want.

No, you can't.  In a "classical" instrument, the input comes from (surprise) the VOR receiver or ADF, which was usually a separate instrument from your GPS navigator.  If it WAS driven by the GPS device, then it would point to...ta da...the *next waypoint in the GPS flight plan*.

Even more strange is the concept that the HSI and both BRG are tied together to the same waypoint - unless you install additional hardware, for which there is no logical reason

It's not strange at all...it's just strange to you because you only have ONE device (SV) outputting info on a single waypoint (exactly the same as if you had NO SV GPS at all, which is an option, and only one other GPS box, like a Garmin 430/530.

There may be no logical reason for YOU to install a separate VOR receiver, but that's not the fault of SV.  That's YOUR choice of how you designed YOUR panel.

 

[Axel]

You're trolling and just trying to pick a fight with the Dynon team to make them look bad.

Don't be agressive and insulting, Steve, try to understand what I'm saying:

1) In a GPS system there is no need for separate VOR/ADF inputs, so asking to connect additional receivers just to get an (off-route) bearing is odd, very odd.

It's just a question of computing two bearings and display them.

2) HSI and the BRGs are tied together (as Mr. Dynon explained) so I took the example of HSI in my last post because it was more work to program an HSI, but I could have included BRG1 and 2.
The point was to counter the killer argument "look at the map!"

My basic point is always the same:
Dynon goes to great pains simulating classical instruments - despite the map. Why not make these instruments work as they would in a classical configuration, i.e. to be set separately to point to some station/waypoint (without buying separate hardware)?

 

[RVDan]

You ask why not make the instruments work as they would in a classical configuration- that is exactly what they do.  In a classical configuration there is a separate nav source for each pointer.  That is what enables one to assign a different task for each pointer.

What I think you mean is that you want them to simulate separate nav sources using a single GPS source so that you can select a separate task for each pointer?  This would be unique.  Once again I ask, what do you need this for? If you are looking to identify intersections for IFR, then you will need a nav reciever in any case.

I certify flat panel dispaly systems in all sorts of aircraft, and none will do what you are asking.  Even for $600K you can't get this.  Dynon gives us great value. 

 

[Axel]

You ask why not make the instruments work as they would in a classical configuration- that is exactly what they do. 

No. In a classic config I can make them point to any VOR/NDB I want. In Skyview not (without going there).

In a classical configuration there is a separate nav source for each pointer.

I humbly admit I don't know what a "nav source" is. As I said when I started this thread, I wanted the discussion restricted to a single GPS only system, "skyview", in order not to confuse the issue with SL40ies, Narcos or whatever. The GPS provides position data, the rest is software, which uses this position data to display whichever information/instruments it likes.
But as the paradigm discussion showed, this is not how the skyview system is organized, otherwise the outcry in this thread about my heresy would not be understandable.

That is what enables one to assign a different task for each pointer.

No. I do not need what you call a separate "nav source" to display a bearing, my single/only source (GPS) is sufficient. If you don't believe it, just push the "nearest" button. All I want is Dynon sort of "pushing the button for me every second" (and only for 2 waypoints: BRG1 and BRG2).

If you are looking to identify intersections for IFR, then you will need a nav reciever in any case.

Uhh ??

I certify flat panel dispaly systems in all sorts of aircraft, and none will do what you are asking.  Even for $600K you can't get this.  Dynon gives us great value. 

I'am just a dumb IFR pilot, flying standard instruments until yesterday. When I see something that resembles my old RBI, I want to use it as I used my old RBI: pointing to my aunts NDB. Dynon is my first glass panel, and yes, its great value. Which does not prevent me from asking some stupid questions ...

 

[dynonsupport]

Axel,
It appears you are focused on IFR flight.

Something to know is that in the vast majority of places that SkyView gets used (USA, Canada, UK, France, Germany, Brazil), IFR flight is not allowed with SkyView as your navigator. You are legally required to have a VOR radio or certified GPS on board. All you can use SkyView's GPS for is "advisory" information. In some of the countries, IFR isn't even allowed in experimental and light sport planes at all, and SkyView can't go in a certified plane in any of those countries. In places like Canada, you have to have TWO independent VOR receivers to be IFR legal!

While this may not be true in Panama, this is part of the reason why other IFR pilots are not looking for SkyView to behave as if it was multiple navigators. They always have a full suite of other equipment because they have to. Additionally, what we do is basically exactly the way all certified planes work, so what we have is industry standard and is a good training platform for all aircraft.

This, in fact, is why we have an HSI. In most countries, while your GPS needs to be certified, your CDI or HSI does not, but you do have to have a CDI or HSI. So SkyView provides the HSI for your external, certified navigator, and can do it for multiple devices if you are so equipped. It does this for "free" instead of costing $10,000 like a certified HSI does, so it's a feature that Dynon products have had for almost a decade now.

As we have said before, SkyView does not have the ability to point each bearing pointer at a specific GPS waypoint because nobody has asked for it before. We've added your request to the large pile of features people have asked for, and we will push it higher on the list if more people ask. We have a lot of things we still want to do in SkyView, and the best we can do is prioritize them by how many people want them. We're happy to re-adjust priorities (and often do) as we learn about things we never considered before that our customers tell us would be useful.

--Ian Jordan
   Chief Systems Architect
   Dynon Avionics

 

[Axel]

"poor mans off-route-RBI"

thank you for your response, Ian, it clarified a lot.

As we have said before, SkyView does not have the ability to point each bearing pointer at a specific GPS waypoint because nobody has asked for it before.

Originally, I didn't want to make a feature request. I thought I was making a mistake in the BRG setup, so obvious it was to me that a bearing needle could point to some arbitrary waypoint.

But ok, I will stand in line and wait until other pilots want off-route bearings, too. Judging from the thread, though, there is not much hope. My only hope are the Dynon programmers, because I am sure, they will not find it difficult to program.

And, please note, Ian, my request does not change the basic Skyview paradigm:
The fans of external nav sources can still connect their SL40ies, Narcos, Kings and as many additional GPS receivers as their daddy is willing to pay for.

My skyview-only version will be just "poor mans off-route-RBI".

 

[GalinHdz]

I humbly admit I don't know what a "nav source" is. As I said when I started this thread, I wanted the discussion restricted to a single GPS only system, "skyview", in order not to confuse the issue with SL40ies, Narcos or whatever. The GPS provides position data, the rest is software, which uses this position data to display whichever information/instruments it likes.
But as the paradigm discussion showed, this is not how the skyview system is organized, otherwise the outcry in this thread about my heresy would not be understandable.

I think you are mixing what the Skyview is supposed to do (display whatever is sent to it) and what the navigation source, be it an external GPS; Skyview's internal GPS; a VOR or NDB is supposed to do (output navigation information).

No. I do not need what you call a separate "nav source" to display a bearing, my single/only source (GPS) is sufficient. If you don't believe it, just push the "nearest" button. All I want is Dynon sort of "pushing the button for me every second" (and only for 2 waypoints: BRG1 and BRG2).

By going to the NEAREST section in your GPS you see what is nearest, but it can't output that information until you select it which override the current location. Do you have a GPS unit that can output data to two different locations, not just display a second location on a separate page? I don't know of any navigation unit that can output navigation information to two locations at the same time. Display them yes. Navigate to them no. Two VERY different things.

The G430/530 units do this because they are actually two separate navigation pieces of equipment (GPS/VOR) in one box.

 

[swatson999]

Originally, I didn't want to make a feature request.

Well, you are. And mind you, I actually think this would be a really cool feature, but it's not the way any other system *including a "classical" RMI* work.

Think about it...an RMI connected to a VOR can only point ONE needle at the VOR. It can't point one needle at the VOR you've tuned in, and the other needle to some other VOR *UNLESS* you have a second VOR hooked up to it.

Similarly, if you have no SV, but a 430/530, and somehow connected the GPS side to an RMI, the RMI can *only* point to the selected next waypoint. There's no way for the Garmin to tell the RMI to point the second needle to some other item in its database.

Essentially, EACH needle on the SV - the HSI course, BRG1 and BRG2 - needs its OWN navigation input from some source. Exactly like a mechanical HSI and an RMI in the planes you've been flying.

That's not to say that it wouldn't be cool to go into the database on SV, find a particular item and then assign that to one of the BRG pointers and have it point to that location.

It's just not what the current aviation standard is...so attacking Dynon for not doing it, or calling it a design *error*, when what you want is something totally new to ANY system, is a bit, shall we say, bold.

It's not a "poor man's RMI"...it's limited by your lack of equipment. And that's your choice, but it's not Dynon's fault.

 

[Axel]

By going to the NEAREST section in your GPS you see what is nearest, but it can't output that information until you select it which override the current location.

As I said, I am a dumb pilot and somewhat slow understanding, so please explain:
Why can Skyview not show me a bearing it knows, without changing my current waypoint/FP?

I only referred to the nearest menu to prove that the information and interface type exist, not to go there.
So I consider what I want is a small step: select a point from "nearest" and set the needle. Done.

 

[GalinHdz]

By going to the NEAREST section in your GPS you see what is nearest, but it can't output that information until you select it which override the current location.

As I said, I am a dumb pilot and somewhat slow understanding, so please explain:
Why can Skyview not show me a bearing it knows, without changing my current waypoint/FP?

I only referred to the nearest menu to prove that the information and interface type exist, not to go there.
So I consider what I want is a small step: select a point from "nearest" and set the needle. Done.

I will have to let DYNON answer that since it might be something that is easier said than done. I imagine there is a lot more involved than just a small software change or some other GPS units would have that capability by now and I don't know of any unit that does it, TSO'd or not.

I, for one, don't need it but that is just me.

 

[rvator51]

I think that Axel's idea of using the Skyview database to drive one of the BRG pointers is pretty cool. Add me to the list of people that would like to have this feature.

 

[dynonsupport]

As was said before, the issue here is not computational, it's the user interface. Given that it's my job to worry about these things, let me just throw out a few issues so you can see that something like this isn't just a few lines of code. Don't mean to sound discouraging, I just want to show how seriously we take any update and why we don't just do things on a whim, and why adding anything is complex. These aren't issues that can't be overcome, because we overcome them with every feature we add, but they are the reason we don't just say "make bearing pointers point wherever you want" and it magically happens in the next release with a few lines of code:

0) Let's agree that calculating the bearing is easy inside the computer because it is. This is not the issue.

1) We can't break the HSI for all our traditional customers. This means the HSI needs to still work with the primary selections being GPS1, GPS2, NAV1, NAV2, etc. This also means the bearings need the same selections. Pressing BRG1 needs to cycle through the same list it used to, without adding steps for customers that don't use this new feature.

So we now need a special mode where it acts different, without getting in the way of traditional use. It also needs to clearly identify itself in this mode.

2) The user needs to know, at all times, where the bearing pointer is going. Right now all we have space for is seven characters such as SKYVIEW. When it's going to Auntie M's Chicken Farm, that needs to be clear. It's totally unacceptable to have it say SKYVIEW when it's not going to SKYVIEW's fight plan, but some other waypoint.

It's also not OK to say KPAE since it's totally invisible what device is being used to create the bearing. The pilot must know how that bearing is being sourced.

What do you do if the user has just chosen a random lat/long to get a bearing to? How do you name that?

Is just showing SKY PAE okay? Will that make people think it's coming from a NAV radio since SkyView might be connected to a NAV radio and PAE is a VOR?

3) The user needs a way to verify where it's pointed even if it says SKY PAE. So I need a UI that allows the user to choose BRG1 and then ask where it's pointed and the system to give the airport, waypoint, or lat/long. This is why we have a flight plan list for flight plans and each one can be selected and get more info. The flight plan is also shown on the map, so you have two ways to see what your flight plan is.

Just having SKY PAE on the HSI isn't good enough. What if there are two PAEs in the world? Which one do I have selected?

4) You need something, somewhere in the system that says "I want what I am looking at right now to become a bearing pointer source."

That option needs to allow BRG1 or BRG2, so it can't be a simple single button press.

That option needs to exist in NRST, INFO, Flight planning, and probably other places. Which means we need a button or method in all of those menus. And all of those menus are full right now.

There needs to be a way to go to the location of the pointer since you want to be able to point somewhere arbitrary and go there, not just points in the GPS database.

Does pressing this just override your current bearing pointer? Even if it was to NAV3 which was a real VOR?

If I press BRG1 and move from SKY PAE to NAV1, is that now lost, or can I rotate SKYVIEW, NAV1, SKY PAE? Does that SKY PAE persist forever, or until I reboot, or ???

5) These settings and selections need to be added to the user datalog

6) These settings and selections need to be saved across boot cycles

7) These settings and selections need to be synchronized across screens

8) The user manual needs to be updated

9) We need to ground and flight test the feature

If anyone out there thinks they can implement all of that in a few lines of code, we have a job opening for you.

You can now see why GPS units put out one output. The whole device is dedicated to that. It has one flight plan, one display of where you are. This avoids a huge amount of complexity. When you click on something, it doesn't need to wonder "do they mean this for the primary flight plan, BRG 1, or BRG 2?"

As you can see, we take all additions to our system quite seriously, and it takes a lot of thought to make SkyView work smoothly and intuitively, but we think it makes a superior product, and I'm quite proud of what SkyView has grown to be over the last few years with this kind of thought given to each feature.

--Ian Jordan

 

[dynonsupport]

I think that Axel's idea of using the Skyview database to drive one of the BRG pointers is pretty cool.

It's cool. But what would you use it for? We're still struggling to find a good description of the use that isn't IFR flight where external devices are legally required.

It really, really helps to be able to envision the use case when specifying the feature. It may also help us describe an alternate way to do something. None of the 20 pilots at Dynon have ever had a use for it before which is why it wasn't on the list until now. But that's why we have a customer forum too!

 

[rvator51]

I was thinking of uses such as having the BRG2 pointer set on an alternate airport that I might go to for weather reasons or have it point to an interesting feature I want to observe as I am on a trip. Or point to the tethered balloon location as I go by it in New Mexico. I think I could come up with a lot of things I could use it for if I thought about it for a while. The list of things that need to be done is daunting at first. Heres is an initial thought.
Why cant you just have the Skyview set as the next nav source? Such as NAV2 or NAV 3? "NAV" already doesnt tell us what the nav source is so have the Skyview follow the same nav logic. Skyview would just act as another NAV source. That should cut down on the coding needed?

 

[ckurz7000]

Hi guys, please excuse me for jumping in on this thread although it's alread a couple of weeks old. I am loosely associated with an aircraft manufacturer who has recently switched from MGL avionics to the Dynon Skyview line of EFIS. I mention this because the paradigm used with the MGL is different. Let me explain:

The internal hardware GPS engine is, at the lowest level used as a position/bearing/distance generator. Information from it is used to emulate "real" instruments which the user interacts with such as VORs, or even a GPS itself. The information of these emulated instruments is displayed by various widgets on the screen such as a CDI, HSI or moving map.

In essence, there are three layers involved:

1) the hardware GPS which generates the required information.

2) an intermediary level which uses this information to emulate verious kinds of instruments

3) a user interface level which uses outputs from real or emulated instruments and displays it on the screen.

Within this paradigm I can still have the HSI perform the same task, i.e., take the information provided by an external navigation source such as a VOR, GPS or NDB. But now, I can choose between a real hardware VOR I might have installed in the panel or an emulated VOR which is simulated by the intermediary software layer.

To the HSI it's all the same. It doesn't know the difference. To the user this is also very intuitive. Everything on the screen behaves like a real VOR except its emulated output is generated from GPS data.

I know that this proposition constitutes more than a couple lines of code. But, to me, it provides a very flexible, extensible and intuitive way of presenting navigation data. There is hardly any change with respect to how the HSI behaves as compared to a classical HSI. And, furthermore, I can use the hardware GPS to its full advantage.

How`s that sound?

-- Chris.

 

[Edwardoc]

The Blue Mountain EFIS 1 had what Axel is asking for and it was referred to as Virtual VOR. You merely had to go to the Virtual VOR menu and dial in a fix or VOR ID and it would drive a bearing pointer indicating a direct course and give you a GPS derived DME to that point. Meanwhile the HSI course indicator was being driven by what ever you had selected i.e. GPS derived course or if you had a VOR and had it selected as the source, a VOR course. It was very handy for telling Center you position from a fix or VOR close by while the Auto pilot was tracking a course direct to a point on a flight plan that might be 600 miles away using the GPS. The bearing pointers were different colors . The virtual VOR would only point to fixes or VORs I think but you might have been able to load user defined points but I don't recall how you did that.

 

[dabear]

FYI...You can already tell Center where you are relative to an airport, VOR, NDB, or Fix.  Check out the Nearest button.
pg 7-28 of the user manual rev M.

 

[swatson999]

The internal hardware GPS engine is, at the lowest level used as a position/bearing/distance generator.

Couple of things...I don't want to reverse engineer Dynon's architecture, but...

GPS hardware does NOT provide bearing or distance information. The GPS hardware itself within a system provides only the position and time (and depending on the box, velocity as derived from position via numerical differentiation or simple delta-position/delta-time). It is often called "PVT" for position/velocity/time as solved by the GPS receiver. At the very lowest level, what it solves for is X,Y,Z,t, with X,Y and Z computed in earth-centered, earth-fixed (ECEF) position and GPS time.

Those values are then converted to various things, such as UTM northings and eastings, latitude/longitude, etc., and usually to UTC time (which is not GPS time).

There is other information in the GPS data, depending on receiver and application, such as Doppler shift information, carrier phase, etc. But the bottom line is that all it does is give position, velocity and time.

Add some sort of database, and now it can be used by the next layer of software to compute distances, bearings, time-to-waypoints, etc.

That implies that your diagrams are wrong...GPS PVT data is an input into module which, along with the information for some database item, computes various bits of information which are then output from there to some sort of user interface.

What you then would have in your drawing is a single GPS computation outputting data which is then accessed by several different modules, each one computing whatever information it wants and then passing THAT information to some interface device or component of a display.

Second thing to keep in mind is that Dynon's HSI with BRG pointers is simply acting as 3 user interface elements (i.e., devices) combined into a single graphical element. All the talk about HSIs doing bearing computations for RMI-like pointers, but using the word "HSI" to describe it, is somewhat incorrect, I think. If you want to think of it more clearly, consider each of the 3 elements (HSI, BRG1, BRG2) as completely separate devices.

Now, your diagram would have

GPS PVT->HSI nav computation -> HSI
GPS PVT -> BRG1 nav computation -> BRG1
GPS PVT -> BRG2 nav computation -> BRG2

The only tricky part of doing this whole thing is to somehow allow the user to easily select database items for the BRG1 and BRG2 computations to use *other than* the one that is being used for the HSI computations (nominally, a direct-to or flight-planned waypoint). And you somehow have to show that on the display so it is unambiguous.

It's not so much a "virtual VOR" as it is a "simulated RMI"...VORs give you radials, you can select which one via an OBS, you get course deviation, etc. That's all part of the HSI. BRG pointers don't give you any of that, just a bearing to the station (or database item).

It's not hard, and there's not doubt that a well-architected system would use common code modules for the computations (and display), it's just a matter of having two additional things to keep track of in the code (the BRG database items selected). In fact, you could write it so that you could have N BRG pointers, if you wanted to generalize the code.

I think the code would be pretty simple to do, it's the UI part that gets tricky, that's all.

Sorry for the long post, I just wanted to clear up some terminology...I used to develop GPS receivers, so I get kind of itchy when people say that GPS hardware computes *navigation* solutions...GPS will work just fine with NO database other than reference datums and ellipsoids. (In fact, it'll work without those, too, but ECEF XYZ coordinates aren't very useful).

 

[ckurz7000]

Sorry for the long post, I just wanted to clear up some terminology...I used to develop GPS receivers, so I get kind of itchy when people say that GPS hardware computes *navigation* solutions...GPS will work just fine with NO database other than reference datums and ellipsoids.  (In fact, it'll work without those, too, but ECEF XYZ coordinates aren't very useful).

Hi Steve, thanks for pointing this out. I actually was well aware of this fact but tried to make a different point. Namely, that there are three seperate entities involved:

1) The GPS which generats position information (after all, even velocity is derived from position information).

2) Software modules which take this information, combine it with data from a database and emulate VORs or NDBS or even GPSs.

3) Display widgets with which the user interacts, such as a HSI. The HSI uses either "real" output from a VOR receiver in the panel or emulated output from a software module which is ultimately GPS based. The point is that HSI doesn't neet to know and the user can interact with it just as a normal HSI in any old plane would work.

-- Chris.