![]() |
no "+V" |
Post Reply ![]() |
Author | ||
oskrypuch ![]() Senior Member ![]() Joined: 09 Nov 2012 Location: CYFD Status: Offline Points: 3062 |
![]() ![]() ![]() ![]() ![]() Posted: 28 Aug 2014 at 6:01pm |
|
Oh dear, that is a nuisance. Will this firmware update slip into production units as it becomes available, or will we have to purchase it? If the latter, that would be kind of crazy. * Orest Edited by oskrypuch - 28 Aug 2014 at 6:02pm |
||
![]() |
||
pburger ![]() Senior Member ![]() ![]() Joined: 26 Dec 2013 Location: United States Status: Offline Points: 406 |
![]() ![]() ![]() ![]() ![]() |
|
Orest,
As far as I'm concerned, we already purchased that functionality!! I've got to think it will just be a simple update with no charge. If that is an add-on purchase, that might be enough for me to drop the whole thing. I'm trying hard to keep the faith...
|
||
![]() |
||
FORANE ![]() Groupie ![]() ![]() Joined: 04 May 2013 Location: 0A9 Status: Offline Points: 57 |
![]() ![]() ![]() ![]() ![]() |
|
Guys, this is a minor issue. At least the approaches involved are included in the database and selectable. I have a shiny GTN 650 which doesn't even have the approach in the database for an airport I regularly use.
|
||
Lancair 235/320
RV-9A |
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
Orest! That is an uncharacteristic leap!
Maybe I should have done better on the original post so let me try now..... Percentage-wise, there are a tiny number of published LP+V approaches in the world. The initial release of IFD540 didn't support LP+V for reasons that are either too inane to go into here or because I'm not bright enough to fully understand. Suffice it to say we found a way to add LP+V capability in the system which took a code change. We will include that in the next software release. There is no way we'll charge for that. I didn't mean to imply that in any way. The initial release does support LPV, LNAV/VNAV, LNAV+V, LNAV, and LP approaches. For reference, we've already released a 2nd software release since the original cert. These kinds of minor releases may happen often as we repair bugs, make minor improvements, or add bits of functionality. I think the standard "past performance does not guarantee future results" kind of disclaimer is worth typing in that you shouldn't assume we'll have one release per month but we'll spit releases out on an as-needed or when-it-makes-sense basis. We have no intent to ever charge for bug fix releases or minor functionality adds. We do intend to provide mechanisms to "opt-in" for releases that have major functionality adds that warrant a $ charge. In those cases, we intend to provide a mechanism that allows all to get the release if it contains bug fixes and minor improvements at no charge and if you want the $ chargeable function, you can optionally elect to pay for it. IOUs and functions like +V that you think were part of the original purchase are NOT appropriate to charge $ for. Keep the faith man! It shouldn't be hard to do so. But, please let me/us know if that gets hard. Seriously. |
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
oskrypuch ![]() Senior Member ![]() Joined: 09 Nov 2012 Location: CYFD Status: Offline Points: 3062 |
![]() ![]() ![]() ![]() ![]() |
|
My mistake, and my apologies, and I thought the comment referenced the very common LNAV+V approaches.
Ah very good, excellent construct. * Orest Edited by oskrypuch - 28 Aug 2014 at 7:48pm |
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
Well..... once again, I wasn't complete in my description of the problem set.
LNAV+V is supported in the initial release IF you have a baro input like and Aspen PFD or G500/600 or air data computer. Just as we have done with LP+V, we found a way to support LNAV+V for those folks who don't have a baro input source. That too, will be included in the next software release and will be no $ charge.
|
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
ddgates ![]() Senior Member ![]() ![]() Joined: 12 Aug 2011 Location: Deer Valley Status: Offline Points: 1100 |
![]() ![]() ![]() ![]() ![]() |
|
Just as a suggestion, or rule of thumb.
My thinking on software revisions runs along this line as it relates to early adopters. The yardstick is to compare the functionality to what a new buyer would get. If you have functionality which would be standard to a new buyer then the early adopters should get those things without up charge as "standard equipment", at least for a reasonable amount of time. If whatever the bell/whistle is turns out to be an option for a new buyer to purchase or not purchase, then it is fair to approach the same bell/whistle in the same fashion to an early adopter. But of course we early adopters should be treated a tad better <g>. I am thinking, though, that there is certainly functionality which is going to be the stock machine which didn't make the cut line at time of STC, so I would expect that such things as TWX670 full mode display, the +V, and so forth to be looked at that way.
|
||
David Gates
|
||
![]() |
||
oskrypuch ![]() Senior Member ![]() Joined: 09 Nov 2012 Location: CYFD Status: Offline Points: 3062 |
![]() ![]() ![]() ![]() ![]() |
|
Ah, the old BARO input, which I now have. Oh, and if you can slide the Avidyne Plantain into one of those slipstream firmware updates, you will make me feel much better, heck I've even pay for that one. * Orest Edited by oskrypuch - 28 Aug 2014 at 8:19pm |
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
Ahh, I forgot about the new nomenclature of "Avidyne Plantain". We'll be sure to put one of our engineers with Central American ancestry on that one.....
|
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
Paul ![]() Senior Member ![]() ![]() Joined: 17 Aug 2012 Location: Massachusetts Status: Offline Points: 285 |
![]() ![]() ![]() ![]() ![]() |
|
Orest has been very patient (and subtle). You should sneak that feature in for him if you can.
|
||
![]() |
||
brou0040 ![]() Senior Member ![]() Joined: 13 Dec 2012 Location: KIYK Status: Offline Points: 722 |
![]() ![]() ![]() ![]() ![]() |
|
Part of the rub is that we were also sold undisclosed new features and those haven't been delivered - potentially wifi counts depending on what comes in the future to enable the hardware. Now we are being told the rest of these features are "new capabilities" and we'll have to pay for them. Not only that, but we'll have to most likely pay the dealer for these bug fixes, so they aren't free.
|
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
No, not true. We have never said, nor will we ever say that "the rest of these feature are new capabilities and you'll have to pay for them".
Nor is it fair to assume that the end user has to pay for bug fixes via some dealer bill. The typical scenario for a pure bug fix release is a no charge release to the end user and Avidyne covering the installer's time. The simple rule is that if it's our mistake, we don't make you pay. I would encourage all readers to not jump to any conclusions. Judge each release/situation on its own merits. I would fully expect anyone to express their opinion when a release is announced and what it's implementation details are but to speculate on the unknown is not worth the internet bits/bandwidth or your angst. We're not a non-profit company but we surely aren't in the business of screwing over our valued customers.
|
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
Paul ![]() Senior Member ![]() ![]() Joined: 17 Aug 2012 Location: Massachusetts Status: Offline Points: 285 |
![]() ![]() ![]() ![]() ![]() |
|
Steve,
It may be that we're sufficiently used to the way certain other companies treat us that we make incorrect assumptions. Some us assumed we'd be charged through the nose for everything, including Avidyne's mistakes. And we're happy to find out we are wrong. Perhaps you or someone at Avidyne can write up the update/upgrade policy and publish it here and on the avidyne.com website? An announced customer-friendly policy would show a difference between you and some other companies. |
||
![]() |
||
Old Bob ![]() Newbie ![]() ![]() Joined: 02 Jul 2014 Location: LL22 Status: Offline Points: 10 |
![]() ![]() ![]() ![]() ![]() |
|
Good Morning Paul, While my recent messages have shown me to be a "newbie, I ordered my IFD 540 in early August of 2011 I am happy with the way Avidyne has communicated with us all. I also am just as frustrated as you are by all of the delays, but having dealt with the FAA since it was first organized, I realize that, like all bureaucracies, it gets harder and harder to deal with. I think trying to get Avidyne to write a "policy message" would be a waste of time and would likely be a step in the wrong direction. Just be happy! Happy Skies, Old Bob PS Avidyne has responded to the desire of a few of us who think the +V function is a bad idea by making provisions to individually remove that function. Great deal for those of us who feel that way. |
||
![]() |
||
ddgates ![]() Senior Member ![]() ![]() Joined: 12 Aug 2011 Location: Deer Valley Status: Offline Points: 1100 |
![]() ![]() ![]() ![]() ![]() |
|
With all due respect, and not wishing to bash anybody, the current delays appear to have nothing to do with the FAA.
|
||
David Gates
|
||
![]() |
||
Paul ![]() Senior Member ![]() ![]() Joined: 17 Aug 2012 Location: Massachusetts Status: Offline Points: 285 |
![]() ![]() ![]() ![]() ![]() |
|
Hi Bob,
Steve's communications are great. But communications from other parts of Avidyne have not been so good. I'm still waiting for the salesman I talked to in March to call me back - he could have probably sold me an Avidyne audio panel if he had done so. The IFD looks like it has great engineering but I shouldn't get important information (even if it is good news) about policies in a forum note titled "no +V". It should be on the Avidyne website. And their salespeople should be using it to beat up on the competition. Then they will sell more IFDs and make enough money that they can hire an engineer to implement Musa acuminata. |
||
![]() |
||
oskrypuch ![]() Senior Member ![]() Joined: 09 Nov 2012 Location: CYFD Status: Offline Points: 3062 |
![]() ![]() ![]() ![]() ![]() |
|
Yes, yes, please! * Orest |
||
![]() |
||
chflyer ![]() Senior Member ![]() ![]() Joined: 24 Jan 2013 Location: LSZK Status: Offline Points: 1054 |
![]() ![]() ![]() ![]() ![]() |
|
Steve,
You made the following comment around the end of August:
Pending receipt and installation of my IFD540/AXP340 combo, I have a couple questions to be sure I am clear on the meaning of your comment and the term "baro input": 1) By "baro input" do you mean only baro-corrected altitude sources per 6.8.1.2 of IFD540 IM p70, to the exclusion of the uncorrected sources in 6.8.1.1? 2) I currently have a Sandia 5-35 with G330 (not ES). So if my new installation feeds alt info via RS232 from the Sandia to the AXP340 which then relays it via RS232 to the IFD540, this DOES NOT qualify as baro input. Correct? 3) What config is anticipated under 6.8.1.2(3) "ARINC from Transponder"? Is there a specific transponder that provides this? (vs 6.8.1.1(5) "RS232 altitude encoder" ... i.e. relayed via AXP340). Why does ARINC data qualify while RS232 data does not? I do not have an Aspen, G500/600, or Shadin ADC. Assuming that my installation does not meet the "baro input" requirement, do you know yet which release will support LP+V & LNAV+V without it? |
||
Vince
|
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
Vince,
1. Yes. 2. Correct (but I am going to double check something on 5 Jan so standby for a possible update). 3. I need to do some homework on this to refresh my memory. I should have that done by about 5 Jan and will repost when I do. As for the question about what release supplies +V for everybody, that will be Release 10.1 which will be shipping in the spring time. I will start a Release 10.1.0.0 thread (release content and schedule updates) as soon as Rel 10.0.3.0 is certified.
|
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
Homework complete. Here are some more in-depth answers:
Regarding #1, if a device sends ARINC 429 label 204 (baro-corrected altitude) and the input is configured for the following priority-sorted list, it will be used for the system-wide baro-corrected altitude value. We are not performing any exclusion of 6.8.1.1 sources. 6.8.1.1 & 6.8.1.2 both include ARINC 429 EFIS as an option. The full list of ARINC 429 selections that allow altitude data is as follows: 1. Airdata 2. Airdata/AHRS 3. Garmin GDU 4. EFIS/Airdata 5. Honeywell EFIS 6. Garmin GAD42 7. GTX330 8. GTX330 w/ Traffic 9. Traffic Advisory
Regarding #2, the AXP340 will support the Icarus/Trimble/Garmin format, or RMS format. The AXP340 will always relay out the Icarus/Trimble/Garmin format. The Sandia 5-35 supports the Trimble/Garmin format (and an MX20 format) so the Trimble/Garmin format is the likely configuration & connection between the Sandia and the AXP340. The installer should know that the parallel encoder output of the Sandia should not be connected to the AXP340 if he elects to use the RS232 format. The RS232 data is uncorrected pressure altitude, not baro-corrected altitude. Starting in Release 10.1.0.0 (spring 2015) the IFD540 will use baro-corrected altitude when available, and fall
back to GPS-derived MSL altitude when baro-altitude is not available.
Regarding #3, ARINC from
Transponder:
Summary: 1. Baro input means baro-corrected altitude, regardless of the source. No exclusions were implied. 2. Sandia does not qualify as baro input. 3. GTX330 data aggregation of ARINC 429 data, still requires label 204 for the GTX to pass-through label 204. |
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
||
chflyer ![]() Senior Member ![]() ![]() Joined: 24 Jan 2013 Location: LSZK Status: Offline Points: 1054 |
![]() ![]() ![]() ![]() ![]() |
|
Thanks for the detailed clarification, Steve. It helps me to ask the right questions of my installer to make sure that the installation works as desired including +V without further intervention once 10.1.0.0 becomes available.
|
||
Vince
|
||
![]() |
||
mfb ![]() Senior Member ![]() Joined: 20 Dec 2014 Location: KATW Status: Offline Points: 293 |
![]() ![]() ![]() ![]() ![]() |
|
The IFD540 installation manual states that the unit can be connected to an encoding altimeter so that it relieves uncorrected pressure altitude.
Is there any reason to do this? It sounds like the IFD540 uses GPS altitude if baro-corrected altitude is not available. What is raw pressure altitude used for? What goes away if pressure altitude is not available? Thanks Mike |
||
![]() |
||
pburger ![]() Senior Member ![]() ![]() Joined: 26 Dec 2013 Location: United States Status: Offline Points: 406 |
![]() ![]() ![]() ![]() ![]() |
|
Was this ever answered? I realize my shop did not connect the AXP-340 pressure altitude to the IFD-540. I just included that in a long squawk list to them. I'm wondering now if it is needed at all. Can anyone shed any light on this? |
||
![]() |
||
Leonard ![]() Senior Member ![]() ![]() Joined: 05 Jul 2012 Location: Lafayette LA Status: Offline Points: 107 |
![]() ![]() ![]() ![]() ![]() |
|
But don't let him know and see how long it takes for him to find it. I bet it won't take him long. Just hope he's on the ground. Wouldn't want him to go in banana shock while he's up in the air. Lol Edited by Leonard - 27 Mar 2015 at 9:14pm |
||
![]() |
||
oskrypuch ![]() Senior Member ![]() Joined: 09 Nov 2012 Location: CYFD Status: Offline Points: 3062 |
![]() ![]() ![]() ![]() ![]() |
|
Ho, ho, ho, I'm keeping a careful eye out!
* Orest |
||
![]() |
||
AviJake ![]() Admin Group ![]() Joined: 26 Mar 2009 Location: Lincoln MA Status: Offline Points: 2815 |
![]() ![]() ![]() ![]() ![]() |
|
I need to check on a few things on Monday but here's a snippet from the pending AXP340 Installation Manual. See the two statements I put in bold red. This is obviously focused on the AXP340 but the thing I need to check on is my memory that this was the motivation behind the IFD540 IM note you reference. ++++++++++++ From Pending AXP340 IM ++++++++++++++++++ The AXP340 must be
connected to an approved altitude encoding source. The AXP340 can use either a
parallel Gillham code altitude input, or serial RS232 altitude input. Both of
these interfaces are on the 24 way connector.
If the altitude encoder you are using offers both, we recommend using
the RS232 serial input. Serial formats
allow a higher resolution altitude representation that can be used by Mode S
interrogations, whereas parallel Gillham (gray) code format can only represent
altitude to the nearest 100 feet. You
must choose between serial or parallel Gillham formats – you should NOT connect
both. If a parallel Gillham encoder is connected the AXP340 will always use
that as the altitude source even if a serial encoder is also connected. The parallel Gillham encoder
inputs are active when the voltage to ground is pulled below approximately 4
Volts. The AXP340 includes internal
isolation diodes which prevent the unit from pulling the encoder lines to
ground when the transponder is switched off.
The AXP340 can therefore share the altitude inputs with other devices
without needing external isolation. Parallel Gillham output
altitude encoders intended for operation below 30,000 feet may not have a
signal connection for D4. In an aircraft
with a service ceiling below 30,000 feet input D4 will never be active, and can
safely be left unconnected. The serial encoder input
uses RS232 input levels. The
communication should be 9600 bps, no parity.
The AXP340 will correctly recognise either “Icarus/Trimble/Garmin”
format altitude data, or “RMS” format altitude data. Refer to the encoder documentation to
determine jumper settings as appropriate. The AXP340 can also accept Shadin
family Format G, Format S and Format Z air data protocols which supply both
altitude and airspeed information. The
airspeed information can be used to provide an automatic air/ground
determination for an ADS-B installation. The AXP340 includes a
serial altitude output which repeats the altitude received on the encoded input
(either parallel Gillham or serial) for connection to a GPS or other
equipment. The serial output supplies
RS232 output levels, and runs at 9600 bps, no parity. The output format is always “Icarus/Trimble/Garmin”
format. If the altitude source is a
parallel Gillham encoder, the serial output is reported every 0.5 seconds; if
the source is a serial encoder, the output simply repeats the input reports,
each report delayed by up to 10 milliseconds from the corresponding input
report. The AXP340 transponder can
accept altitude from multiple sources, the AXP340 will prioritize the altitude inputs
in the following order:
All the altitude sources
above must meet either TSO-C10( ) or TSO-C88( ) per 14 CFR 91.217. The ADS-B output does not
alter any existing regulatory guidance regarding the barometric altitude
accuracy or resolution. Aircraft operating in Reduced Vertical Separation
Minimum (RVSM) airspace must have the same accuracy and resolution for the
ADS-B airdata transmission. |
||
Steve Jacobson
sjacobson@avidyne.com |
||
![]() |
Post Reply ![]() |
|
Tweet
|
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |