429/232 Steering labels from heading bug
- Thread starter MavSmith
- Start date
This is the feature that has me on the fence in regards to what brand to purchase....
I know Dynon is working on their own autopilot but I would think that it should be simple to output the correct GPS sentences to drive the modern GPS enabled autopilots with a heading bug.
I know Dynon is working on their own autopilot but I would think that it should be simple to output the correct GPS sentences to drive the modern GPS enabled autopilots with a heading bug.
aceflyingservice
New Member
- Joined
- Nov 10, 2005
- Messages
- 65
This would be a very useful enhancement.
Roger Johnson
LongEZ N34JR
Roger Johnson
LongEZ N34JR
- Joined
- Mar 23, 2005
- Messages
- 13,226
This has been discussed before, but here's our current thinking on this topic:
We don't do this just because we're also working on an AP. We understand that lots of people already have APs and it would be nice if they could use the Dynon EFIS to control the AP. Unfortunately, this is not easy at all. Your AP only has one serial input on it. You probably currently use this as the GPS input, so that you can fly GPS flightplans and also so the AP can fly ground track. You can't connect two serial transmitters together, so you can't have the GPS and the EFIS hooked up at the same time.
The only way to hook the EFIS and the GPS up to the AP would be via a switch. When you did this, the AP would fall back to magnetic heading instead of GPS track (TruTrak) or just turn rate (Trio). The magnetic heading of a AP mounted in your panel isn't very good, and you can't fly a magnetic heading if you only have turn rate. So the bug and the AP wouldn't even match since their magnetic info is probably very different, or the AP wouldn't even be able to fly. So to use the bug out of the EFIS with a TruTrak, you'd have to throw a switch, set up the bug on the EFIS, and then you'd be flying a less accurate heading. In comparison with just setting the bug using the knob on the AP, this doesn't seem so convenient. On a Trio, this system doesn't work at all since you must have GPS all the time to navigate.
On top of all of this, it's not trivial for us to send out this data. The only serial port the EFIS has free is the one used for PC updates and datalogging in flight, so you'd lose datalogging, and it's actually quite difficult for us to change the data that comes out here.
ARINC-429 is a slightly different story. We could put the heading bug out on the HS34, and we're willing to do so, but you still run out of ports on your AP. As far as I know, the expensive AP's that support ARINC-429 only have one receive port, so again, you'd have to disconnect GPS to fly our bug. They do make ARINC-429 concatenators (one is in the Garmin 330 transponder), which would allow you to blend the data from a GPS and us, but that's expensive and we imagine somewhat rare.
Beyond all of those issues, none of the experimental AP manufacturers publicly publish the data that they expect, so we're not even 100% sure what they want. The first thing you should ask your AP manufacturer is for them to publish a list of commands accepted or published, just like Dynon does with all of its serial streams (they're in the back of every user guide).
We're always willing to look at new and interesting features, so keep 'em coming. If we're wrong, mistaken, or just not looking at the problem from the right angle, let us know. But we have thought about this issue, and it's not just as simple as "put your heading bug in your serial stream and the AP will follow." The APs out there just aren't designed to take this information in an easy way, so there's no easy way for us to do it.
We don't do this just because we're also working on an AP. We understand that lots of people already have APs and it would be nice if they could use the Dynon EFIS to control the AP. Unfortunately, this is not easy at all. Your AP only has one serial input on it. You probably currently use this as the GPS input, so that you can fly GPS flightplans and also so the AP can fly ground track. You can't connect two serial transmitters together, so you can't have the GPS and the EFIS hooked up at the same time.
The only way to hook the EFIS and the GPS up to the AP would be via a switch. When you did this, the AP would fall back to magnetic heading instead of GPS track (TruTrak) or just turn rate (Trio). The magnetic heading of a AP mounted in your panel isn't very good, and you can't fly a magnetic heading if you only have turn rate. So the bug and the AP wouldn't even match since their magnetic info is probably very different, or the AP wouldn't even be able to fly. So to use the bug out of the EFIS with a TruTrak, you'd have to throw a switch, set up the bug on the EFIS, and then you'd be flying a less accurate heading. In comparison with just setting the bug using the knob on the AP, this doesn't seem so convenient. On a Trio, this system doesn't work at all since you must have GPS all the time to navigate.
On top of all of this, it's not trivial for us to send out this data. The only serial port the EFIS has free is the one used for PC updates and datalogging in flight, so you'd lose datalogging, and it's actually quite difficult for us to change the data that comes out here.
ARINC-429 is a slightly different story. We could put the heading bug out on the HS34, and we're willing to do so, but you still run out of ports on your AP. As far as I know, the expensive AP's that support ARINC-429 only have one receive port, so again, you'd have to disconnect GPS to fly our bug. They do make ARINC-429 concatenators (one is in the Garmin 330 transponder), which would allow you to blend the data from a GPS and us, but that's expensive and we imagine somewhat rare.
Beyond all of those issues, none of the experimental AP manufacturers publicly publish the data that they expect, so we're not even 100% sure what they want. The first thing you should ask your AP manufacturer is for them to publish a list of commands accepted or published, just like Dynon does with all of its serial streams (they're in the back of every user guide).
We're always willing to look at new and interesting features, so keep 'em coming. If we're wrong, mistaken, or just not looking at the problem from the right angle, let us know. But we have thought about this issue, and it's not just as simple as "put your heading bug in your serial stream and the AP will follow." The APs out there just aren't designed to take this information in an easy way, so there's no easy way for us to do it.
Thomas_Schaad
New Member
- Joined
- Mar 23, 2005
- Messages
- 144
I know, Dynon is doing a great job to build products, that satisfy most users needs. So regarding the A/P I do understand Dynon's position absolutely. By looking at my Trio A/P now, I see that it would also work with elderly NavAid servos.
So what I suggest as a helpfull solution to all of us, using Trio's and TruTrack's: Dynon, please build your A/P the way, it works with Trio- and TruTrack Servos. This way we all could simply remove the controlhead of the existing system and could make advantage of the Dynon Installation we all do have
What would be a cool addition as well: I know your points about the dimenssions of the extension module and do absolutely understand them. In regard of the A/P I would suggest to bring to the existing two versions a third one, fitting in a standart 3" instrument whole. This would make it possible to all of us to simply remove the A/P control head and place the Dynon Extension module in this existing cut out. So no ugly panels, no big mods needed and a great system
I know, Rome wasn't built in day either, but let me know what you think about my proposals. Thanks a lot for your attention and
Kind regards
Thomas
So what I suggest as a helpfull solution to all of us, using Trio's and TruTrack's: Dynon, please build your A/P the way, it works with Trio- and TruTrack Servos. This way we all could simply remove the controlhead of the existing system and could make advantage of the Dynon Installation we all do have
What would be a cool addition as well: I know your points about the dimenssions of the extension module and do absolutely understand them. In regard of the A/P I would suggest to bring to the existing two versions a third one, fitting in a standart 3" instrument whole. This would make it possible to all of us to simply remove the A/P control head and place the Dynon Extension module in this existing cut out. So no ugly panels, no big mods needed and a great system
I know, Rome wasn't built in day either, but let me know what you think about my proposals. Thanks a lot for your attention and
Kind regards
Thomas
I appreciate your update on Dynon's current thinking in this regard.
I also understand your limitations on hardware.
What I don't understand is why you can't talk to a modern GPS enabled autopilot and claim you don't know what they need. A $99 Ebay gps that was built 10 years ago can drive an autopilot but Dynon can't figure out the NMEA 0183 stream? Come on guys.....
You already have the GPS signal comming in, you have two extra serial ports on the HS34, you have the ability to adjust the bug on the HS34 etc.
Come up with some way to pass thru the GPS NAV data thru the HS34 to the AP, give the operator a way to switch between GPS Nav (Passthru mode) and Bug modes, and when in bug mode use the GPS data combined with the bug data to derive a heading for the AP and output thru the HS34 as NMEA data the AP understands. A couple of the biggest competitors to Dynon are already doing this and others are soon to do it.
An example of where this would be nice to have all on the EFIS is when enroute, you would be in GPS Nav passthru mode tolling along following the GPS flightplan. Then, you enter controlled airspace and start recieving vectors. No problem, you just press the button on the EFIS to go from GPS Nav to Bug Nav and the EFIS takes care of the conversion and presto, you are flying the bug...
Even if you don't do the passthru function, a simple flip of a panel mounted switch can switch the AP from directly connected to the GPS to being connected to the EFIS (HS34) that should know what heading it on, just use that knowledge and output the correct sentences to the AP to make it fly the bug.
Everyone wants to mimimize the buttons they have to press and the number of devices they have to press them on. A simple switch could take the Dynon out of the loop and feed the AP directly from the GPS in case of failure of the Dynon.
I know that is over simplifying things but you get the idea.
After all, how are you going to integrate your own autopilot? Is it just going to be a stand alone product or is it going to have integration with the EFIS? If it is, what are your plans for integrated features?
I also understand your limitations on hardware.
What I don't understand is why you can't talk to a modern GPS enabled autopilot and claim you don't know what they need. A $99 Ebay gps that was built 10 years ago can drive an autopilot but Dynon can't figure out the NMEA 0183 stream? Come on guys.....
You already have the GPS signal comming in, you have two extra serial ports on the HS34, you have the ability to adjust the bug on the HS34 etc.
Come up with some way to pass thru the GPS NAV data thru the HS34 to the AP, give the operator a way to switch between GPS Nav (Passthru mode) and Bug modes, and when in bug mode use the GPS data combined with the bug data to derive a heading for the AP and output thru the HS34 as NMEA data the AP understands. A couple of the biggest competitors to Dynon are already doing this and others are soon to do it.
An example of where this would be nice to have all on the EFIS is when enroute, you would be in GPS Nav passthru mode tolling along following the GPS flightplan. Then, you enter controlled airspace and start recieving vectors. No problem, you just press the button on the EFIS to go from GPS Nav to Bug Nav and the EFIS takes care of the conversion and presto, you are flying the bug...
Even if you don't do the passthru function, a simple flip of a panel mounted switch can switch the AP from directly connected to the GPS to being connected to the EFIS (HS34) that should know what heading it on, just use that knowledge and output the correct sentences to the AP to make it fly the bug.
Everyone wants to mimimize the buttons they have to press and the number of devices they have to press them on. A simple switch could take the Dynon out of the loop and feed the AP directly from the GPS in case of failure of the Dynon.
I know that is over simplifying things but you get the idea.
After all, how are you going to integrate your own autopilot? Is it just going to be a stand alone product or is it going to have integration with the EFIS? If it is, what are your plans for integrated features?
- Joined
- Mar 23, 2005
- Messages
- 13,226
A $99 GPS does not drive an autopilot. It provides ground track, which the AP then uses to fly. It doesn't tell the AP to go up, down, left, or right. It just says "here's your heading, here's your altitude." Since the AP was directly designed to take this data and use it, the complexity is not in the GPS, it's in the AP which you paid more for than you did for the EFIS. This $99 GPS will only let the AP fly a heading, not a course, but you set the heading you want on the AP, not on the GPS.
Last I checked, no GPS on the planet tells any AP to fly a specific heading. It tells the GPS how far left or right from a specific course line it is. The point of the AP is to fly right over that line. This means that if you turn off the AP, fly off the course line, and turn the AP back on, it doesn't fly a heading, it turns towards the course line, then turns back to the course when it intercepts it. In order to deal with crosswinds, it doesn't even care what heading it maintains in order to keep the CDI at zero. That point in this mode is not heading, its course, and that's a totally different beast.
Due to this fact, I have no idea if the APs even support an input over the serial port that says "fly this heading." No GPS does this, so there isn't a direct reason to support it. The only time they let you fly a heading is when you dial in that heading on the front panel, not via a remote device. They may support it, but it's not part of the standard NMEA sentence, so we need to know what it is they want us to send them, and they don't publish this data if they do accept it.
In order to make the AP fly a heading remotely, without knowing the magic sentence to send the AP, you have to lie to it. You tell it it's flying a course line, but now you have to move that course line around in order to get it to fly a heading. You're actually running another autopilot loop inside the EFIS which is figuring out how to lie to the AP to get it to do what you want, not what the AP thinks it's doing.
Anyway, this can be done, and people have done it. But it's not easy, and it's sure not clean. The AP says "NAV" on it when it's actually flying a heading, and now how well your EFIS's AP is tuned to your airplane affects how stable your AP tracks a heading. It's a mess.
You are correct that the HS34 lets us do this serial trickery, but I imagine not a lot of people will pay $650 to set the AP bug via the EFIS.
One thing I don't understand is how this is better than the way the APs already do it. I've flown a hundred hours behind a TruTrak. When I'm flying enroute, I fly off the GPS flight plan on a course. When I then get a vector, I tap the mode button and dial in the heading. The only difference I see here is where I dial stuff in, not the number of steps required.
As a very final note, the bug on the EFIS is magnetic, the "bug" in the AP is ground track. If we do ever send the AP the EFIS bug to a non-Dynon AP, if there is any wind the two headings will not match. ATC expects you to fly magnetic, not ground track when they give you a vector, so using the AP to fly vectors is already a bit of a problem if its windy out.
Last I checked, no GPS on the planet tells any AP to fly a specific heading. It tells the GPS how far left or right from a specific course line it is. The point of the AP is to fly right over that line. This means that if you turn off the AP, fly off the course line, and turn the AP back on, it doesn't fly a heading, it turns towards the course line, then turns back to the course when it intercepts it. In order to deal with crosswinds, it doesn't even care what heading it maintains in order to keep the CDI at zero. That point in this mode is not heading, its course, and that's a totally different beast.
Due to this fact, I have no idea if the APs even support an input over the serial port that says "fly this heading." No GPS does this, so there isn't a direct reason to support it. The only time they let you fly a heading is when you dial in that heading on the front panel, not via a remote device. They may support it, but it's not part of the standard NMEA sentence, so we need to know what it is they want us to send them, and they don't publish this data if they do accept it.
In order to make the AP fly a heading remotely, without knowing the magic sentence to send the AP, you have to lie to it. You tell it it's flying a course line, but now you have to move that course line around in order to get it to fly a heading. You're actually running another autopilot loop inside the EFIS which is figuring out how to lie to the AP to get it to do what you want, not what the AP thinks it's doing.
Anyway, this can be done, and people have done it. But it's not easy, and it's sure not clean. The AP says "NAV" on it when it's actually flying a heading, and now how well your EFIS's AP is tuned to your airplane affects how stable your AP tracks a heading. It's a mess.
You are correct that the HS34 lets us do this serial trickery, but I imagine not a lot of people will pay $650 to set the AP bug via the EFIS.
One thing I don't understand is how this is better than the way the APs already do it. I've flown a hundred hours behind a TruTrak. When I'm flying enroute, I fly off the GPS flight plan on a course. When I then get a vector, I tap the mode button and dial in the heading. The only difference I see here is where I dial stuff in, not the number of steps required.
As a very final note, the bug on the EFIS is magnetic, the "bug" in the AP is ground track. If we do ever send the AP the EFIS bug to a non-Dynon AP, if there is any wind the two headings will not match. ATC expects you to fly magnetic, not ground track when they give you a vector, so using the AP to fly vectors is already a bit of a problem if its windy out.
- Joined
- Mar 23, 2005
- Messages
- 13,226
Also, Dynon's servos will be cheaper, lighter, sexier, and just better than others out there!
Thanks for the update, I certainly understand the hardware issues with RS232, however with the HS34 ARINC429 provides a hardware soloution. If the problem is just lack of info on on labels, rates/gains etc. I'm sue with a very little effort this could be overcome, afterall some of the info can be found in the Garmin install notes. If nothing else it would provide HS34 purchase incentive for all those guys wanting this feature. Would also make the D10A/HS34 a viable/economical EHSI replacement for all those mecahnical HSI's.
Just some more comments. As indicated, using the NMEA data to provide ground track emulation from the heading bug sounds a bit hard. However the 429 Label (121) is actually roll steering info, that is, it tells the AP to trun left/right, no info about ground track, and are idealy suited for the heading bug. Chelton and others actually do this. And for ATC, exactly what they want. mag heading.
The sole issue that has prevented me from buying two D10As (one dedicated AI and one dedicated HSI) is that I have been advised that the Dynon HSI will not output heading bug data to the A/P.
I, for one, would gladly pay $650 for this functionality, even if the HS34 did nothing else! Without it however, I have no option but to investigate other EFISs that can accomplish this. Descision time is rapidly approaching for me, so if this can be done with some HS34 'trickery', as has been suggested, I would like to know real soon!
I, for one, would gladly pay $650 for this functionality, even if the HS34 did nothing else! Without it however, I have no option but to investigate other EFISs that can accomplish this. Descision time is rapidly approaching for me, so if this can be done with some HS34 'trickery', as has been suggested, I would like to know real soon!
- Joined
- Mar 23, 2005
- Messages
- 13,226
Roll steering info is not just a label with a heading number in it. It literally moves part of the AP into the GPS unit. The thing sending out roll steering says "roll 30 degrees right" (which means 30 degrees of bank, not 30 degrees of heading) not just "roll right" then "stop". Even if you did "roll right" then "stop", you'd still need to anticipate the right time to say "stop." At some point we need to actually charge you for an autopilot, since we're doing all sorts of stuff your $4k AP doesn't even do!
What we will/can support in the HS34 is ARINC label 101G, which is "Selected Heading." This is literally the heading bug. If your AP listens, great. If not, then that's a question for them as to why they don't support a standard label.
RYKG3, there is no current plan to do the "trickery" in the HS34, so if you really are making a decision as you say, a second Dynon EFIS + HS34 is not for you in the near future. You'll need to buy a different system if your primary goal is that the bug on the HSI sync to the AP. The systems out there that do this and talk ARINC429 are 2X the price of us though, and are way bigger physically than a D10A.
What I would like to know is how many of you have Garmin 330's with your ARINC capable autopilots, since that will be required to concatenate the GPS and HS34 data. If anyone has this setup, please let us know, since the main thing preventing us from sending out label 101G out of the HS34 is a lack of equipment to test it with. If you can try this out for us we might want you as a beta tester.
What we will/can support in the HS34 is ARINC label 101G, which is "Selected Heading." This is literally the heading bug. If your AP listens, great. If not, then that's a question for them as to why they don't support a standard label.
RYKG3, there is no current plan to do the "trickery" in the HS34, so if you really are making a decision as you say, a second Dynon EFIS + HS34 is not for you in the near future. You'll need to buy a different system if your primary goal is that the bug on the HSI sync to the AP. The systems out there that do this and talk ARINC429 are 2X the price of us though, and are way bigger physically than a D10A.
What I would like to know is how many of you have Garmin 330's with your ARINC capable autopilots, since that will be required to concatenate the GPS and HS34 data. If anyone has this setup, please let us know, since the main thing preventing us from sending out label 101G out of the HS34 is a lack of equipment to test it with. If you can try this out for us we might want you as a beta tester.
khorton
New Member
This is actually a good solution. You provide the heading bug info via an established standard, and it is then up to the autopilot manufacturers to decide whether they wish to pick up this data. There are enough Dynon products installed that there will be a lot of pressure for the autopilot companies to update their product line to accept 429 data. Eventually one of them will crack and do it, and then the others will have to follow or lose market share.
Three lines of code..
If heading error >20 then roll 30
else role ((heading error /20) * 30)
Endif
At least this would emulate the standard DC/analog style Heading Bug.
What about taking 429 input from GPS and pass thu when Heading bug disabled and replace required Labels when Bug selected.
Also hardware switching of 429 to AP would be quite OK. Could even output a digital signal to drive a relay when the Heading bug is selected. Some Sandel/Garmin installs do this.
Just my 2c's worth..
If heading error >20 then roll 30
else role ((heading error /20) * 30)
Endif
At least this would emulate the standard DC/analog style Heading Bug.
What about taking 429 input from GPS and pass thu when Heading bug disabled and replace required Labels when Bug selected.
Also hardware switching of 429 to AP would be quite OK. Could even output a digital signal to drive a relay when the Heading bug is selected. Some Sandel/Garmin installs do this.
Just my 2c's worth..
Well, it never occurred to me that Dynon was primarily interested making cheap avionics - had I known that, I would have taken up the suggestion of an alternative supplier sooner!
Not that cost (or complexity) is the issue, in this case. Anyone with a reasonable understanding of the technology knows, it is neither difficult, nor expensive, to implement the relatively minor software change that will accomplish the objective perfectly, as the previous writer has indicated. The fact that these suggestions have been met with deafening silence, suggests that there are other factors driving the decision making here.
Its difficult to escape the sense that there is considerable reluctance to provide any feature that may assist the integration of the EFIS with another company's autopilot - could that be because Dynon have their own plans in this regard? Of course a Dynon A/P would be a good thing, when (if) it happens and I'm sure there are plenty of customers who would like to install such a combination in their new project. But, if the strategy was to make the Dynon EFIS compatible with the Dynon A/P ONLY, perhaps as a means of selling more A/Ps, that would be a very flawed plan indeed, in my view. Few, if any, existing owners are going to throw out a very capable and functioning A/P just to upgrade to the Dynon suite, its much more likely (as in my case) that they will go with another EFIS (and new EFIS products are hitting the market every day). Rather counter-productive, wouldn't you say?
Vertical integration can be a good thing, but not when it actually serves to diminish the demand for a company's primary product line. Of course, that may not be Dynon's strategy at all.
Not that cost (or complexity) is the issue, in this case. Anyone with a reasonable understanding of the technology knows, it is neither difficult, nor expensive, to implement the relatively minor software change that will accomplish the objective perfectly, as the previous writer has indicated. The fact that these suggestions have been met with deafening silence, suggests that there are other factors driving the decision making here.
Its difficult to escape the sense that there is considerable reluctance to provide any feature that may assist the integration of the EFIS with another company's autopilot - could that be because Dynon have their own plans in this regard? Of course a Dynon A/P would be a good thing, when (if) it happens and I'm sure there are plenty of customers who would like to install such a combination in their new project. But, if the strategy was to make the Dynon EFIS compatible with the Dynon A/P ONLY, perhaps as a means of selling more A/Ps, that would be a very flawed plan indeed, in my view. Few, if any, existing owners are going to throw out a very capable and functioning A/P just to upgrade to the Dynon suite, its much more likely (as in my case) that they will go with another EFIS (and new EFIS products are hitting the market every day). Rather counter-productive, wouldn't you say?
Vertical integration can be a good thing, but not when it actually serves to diminish the demand for a company's primary product line. Of course, that may not be Dynon's strategy at all.
- Joined
- Mar 23, 2005
- Messages
- 13,226
Given that we basically said we'd support the heading bug out of the HS34 via ARINC-429, that's a pretty unique definition of "deafening silence"
In any case, we try hard to not make promises of future support when they aren't actually being worked on. Other company AP support is not currently something that any engineer is currently working on, so we're not promising it. Unlike many other companies, we want you to make a purchase decision based on what we do today, not what we might do in the future. This loses us specific sales sometimes, but we think its worth it in the long run by not disappointing anyone.
There's actually a great example of this from our past. About 2 years ago a customer had a D100 and a D120 on order from us. At that time we didn't do an HSI. He called us and canceled his order because we didn't do an HSI and a competitor promised they would be doing an HSI when the product shipped. We told him we were sorry to lose his order, and we wished him luck, even though we were working on the HSI internally at that point. 3 months later, we shipped the HSI as a free upgrade for every customer. It took him 6 more months before he even got his unit from the other guys, and then he ran beta software for months.
That customer now works for us as an engineer.
As for the ease of implementing this, Dynon works VERY different from other companies in the Experimental EFIS sector. We don't release stuff unless we have tested it over and over. So a release process for us requires us to write a spec for a feature, implement it, then go through 2-3 months of beta testing. Then we have to document it. Because of this, every feature requires tons of work on our end, no matter how many lines of code someone on a forum guesses it to be. A feature is a feature, and it requires it to be implemented to our standard.
Because of this, our forum isn't full of people asking about bugs or features they were promised months / years ago. People don't need to ask how to use or set something up because we actually have manuals for all of our features.
It should be clear from this discussion that Dynon has considered this support, and for now, we have not considered it a high enough priority to implement. We've had engineering discussions about what it would take, and you'll just have to trust us that it isn't 3, 30, or even 300 lines of code, and even if it was, that's still lots of hours for us when you consider the whole process. Given that Dynon has actually made a UAV that can fly for hours, over the horizon, on its own, then come back, should tell you that we have a pretty good sense of the complexity of this issue. Linear systems do not make an autopilot.
We're sorry if our current product doesn't fit your needs. A quick glance at this forum beyond your first two posts in this thread will show you that Dynon is actually a very customer focused and responsive company. There are tens if not hundreds of features we have implemented based on feedback. Many of them show up as "surprises" in releases, since we do our best to not talk about stuff until it's done. Maybe someday we will fit your needs better, but if your primary need is a heading bug driven over to the AP, we're not your company today. At least we're honest about that. If your needs involve honesty, incredible support, unbeatable prices, proven reliability, software stability, or quick shipping, you're not going to find any experimental EFIS manufacturer that beats Dynon.
In any case, we try hard to not make promises of future support when they aren't actually being worked on. Other company AP support is not currently something that any engineer is currently working on, so we're not promising it. Unlike many other companies, we want you to make a purchase decision based on what we do today, not what we might do in the future. This loses us specific sales sometimes, but we think its worth it in the long run by not disappointing anyone.
There's actually a great example of this from our past. About 2 years ago a customer had a D100 and a D120 on order from us. At that time we didn't do an HSI. He called us and canceled his order because we didn't do an HSI and a competitor promised they would be doing an HSI when the product shipped. We told him we were sorry to lose his order, and we wished him luck, even though we were working on the HSI internally at that point. 3 months later, we shipped the HSI as a free upgrade for every customer. It took him 6 more months before he even got his unit from the other guys, and then he ran beta software for months.
That customer now works for us as an engineer.
As for the ease of implementing this, Dynon works VERY different from other companies in the Experimental EFIS sector. We don't release stuff unless we have tested it over and over. So a release process for us requires us to write a spec for a feature, implement it, then go through 2-3 months of beta testing. Then we have to document it. Because of this, every feature requires tons of work on our end, no matter how many lines of code someone on a forum guesses it to be. A feature is a feature, and it requires it to be implemented to our standard.
Because of this, our forum isn't full of people asking about bugs or features they were promised months / years ago. People don't need to ask how to use or set something up because we actually have manuals for all of our features.
It should be clear from this discussion that Dynon has considered this support, and for now, we have not considered it a high enough priority to implement. We've had engineering discussions about what it would take, and you'll just have to trust us that it isn't 3, 30, or even 300 lines of code, and even if it was, that's still lots of hours for us when you consider the whole process. Given that Dynon has actually made a UAV that can fly for hours, over the horizon, on its own, then come back, should tell you that we have a pretty good sense of the complexity of this issue. Linear systems do not make an autopilot.
We're sorry if our current product doesn't fit your needs. A quick glance at this forum beyond your first two posts in this thread will show you that Dynon is actually a very customer focused and responsive company. There are tens if not hundreds of features we have implemented based on feedback. Many of them show up as "surprises" in releases, since we do our best to not talk about stuff until it's done. Maybe someday we will fit your needs better, but if your primary need is a heading bug driven over to the AP, we're not your company today. At least we're honest about that. If your needs involve honesty, incredible support, unbeatable prices, proven reliability, software stability, or quick shipping, you're not going to find any experimental EFIS manufacturer that beats Dynon.
Thanks for you response. I certainly understand what’s involved in delivering complex software/hardware solutions to an ever changing customer requirement. We do this.. I was being flippant in respect of 3 lines of code. However I would still like to see the possibility of providing Steering data from the heading bug in preference to suggested label 101 as any AP would need the additional Heading data to calculate a steering solution. If you are committed to label 101 maybe the additional actual Mag heading as well (Label 320 I think) would provide the required info to achieve this.
Anyway thanks again for your response. I will watch this space with interest..
Anyway thanks again for your response. I will watch this space with interest..
- Joined
- Mar 23, 2005
- Messages
- 13,226
We already publish Label 320 since the Garmin 430 uses this to calculate wind direction. We publish mag direction, IAS, OAT, TAS, and probably some other stuff I am forgetting. There's already a lot on there which could be handy for a lot of other devices.
jlhrstv
New Member
The label 320, 101G solution sounds good, if certain autopilot manufacturers could be convinced to support it. Are there also labels for current altitude & selected altitude?
Also, some autopilots also support vertical steering like the Trutrak DFII VSGV. These could be steered to the altitude bug as well.
We have a 430W, 330 XPDR along with an HS-34, and would be happy to beta test the software per your request earlier.
My suggestion would be to calculate and output the lateral & vertical steering commands for an extra charge. Perhaps an upgraded HS-34 unit, the HS-35? It could pass through the steering commands from the GPS when the heading bugs are off, substituting commands when the heading bug(s) are selected, or just use an external DPDT switch. This would give Dynon an opportunity to sell some of the hard work they are putting into there autopilot system to customers that already have an autopilot, or who would prefer to purchase another brand autopilot.
An "approach mode" that always passes through GPSS commands would also be helpfull. This could be accomplished with the external switch to bypass the Dynon, connecting the GPS ARINC directly to the AP.
John
Also, some autopilots also support vertical steering like the Trutrak DFII VSGV. These could be steered to the altitude bug as well.
We have a 430W, 330 XPDR along with an HS-34, and would be happy to beta test the software per your request earlier.
My suggestion would be to calculate and output the lateral & vertical steering commands for an extra charge. Perhaps an upgraded HS-34 unit, the HS-35? It could pass through the steering commands from the GPS when the heading bugs are off, substituting commands when the heading bug(s) are selected, or just use an external DPDT switch. This would give Dynon an opportunity to sell some of the hard work they are putting into there autopilot system to customers that already have an autopilot, or who would prefer to purchase another brand autopilot.
An "approach mode" that always passes through GPSS commands would also be helpfull. This could be accomplished with the external switch to bypass the Dynon, connecting the GPS ARINC directly to the AP.
John
"Honesty, incredible support, unbeatable prices, proven reliability, software stability, or quick shipping..." are all highly desirable features and if that's the way Dynon conducts its business, I'm very much impressed.
Unfortunately, even with all of that, a product needs to do what I want it to do - so, as you have pointed out, it seems that Dynon is not my company today.
Pity though, it came real close.
Unfortunately, even with all of that, a product needs to do what I want it to do - so, as you have pointed out, it seems that Dynon is not my company today.
Pity though, it came real close.