Recent content by MGiacomet

Certainly, no changes to what the alert will indicate (“traffic X o’clock, Y miles”) but the feature request is simply a change on WHEN the alert gets triggered. Glad you agree; if you haven’t, don’t forget to upvote :)

Currently traffic alerts are distance-based, e.g., 2, 3, 5, 7 and 10NM. Would be nice to have options like "1 minute", "2 minutes", "5 minutes", etc. based on the closure rate, i.e., dividing the distance to traffic by the difference between your own speed and the traffic's, yielding how much...

This? Still shows absolute altitudes…

Please enlighten me. Where? Like this?… Still shows absolute altitudes. And how are absolute altitudes more helpful to the pilot when one is trying to SEE the traffic out the window?

The current implementation shows the traffic relative position (as "o'clock") but shows the absolute altitude, requiring the pilot to do mental math to figure out where to look for traffic. It would be best if, when a traffic alert is issued (or when using QuickView to see traffic details)...

>>Also, there could be an argument that if you have this feature and use it you actually learn from it. I'd rather have somebody be doing the appropriate entry rather than doing a 5 mi final Well, this would be a deficiency in training and best addressed at that point. There are tools one can...

There are probably rea$on$ why FF has it. Well.. FF has it, so… I wish this doesn’t ever get implemented; we don’t need more airplane “drivers” looking at a magenta line when they should be looking out the window for traffic.

Cool! Don’t forger to upvote (I’ve just done on your post 🙂) here. Hopefully one of them will get traction

You’d need to enter the altimeter setting and have a device that provides pressure altitude, or your actual altitude may not match the callouts to the precision you’d like. Even worse if based solely on GPS

Not really. If the target is in level flight vert speed=0 so you can’t tell anything about it’s climbing ability. If the target is doing slow flight you may think it’s a Cub but may be a Baron

Thanks! Don't forget to upvote if you like the idea ;) As far as timeout... timeouts are always bad in programming (40+ years of Software Engineering, here): they'll always come back to bite some time (pun intended) in the future. The best practice is to let the user be in control, not have...

You are correct. So, my feature request is simply to remove the timer that resets back to ARPT. If a tap happens anywhere and the selected tab doesn’t have data to display, then revert to ARPT Let’s see what others think

As I keep trying to understand the current behavior, I noticed that the 5-second timer doesn’t apply to the NAV tab. I don’t see the reasoning to revert back to ARPT after 5-seconds EXCEPT when the NAV tab is selected… Best to keep the last selected tab than have the convoluted logic/timer...

I think you just agreed with me… Yes the user will get frustrated because iFly ***Is*** forcing the tab back to ARPT after the arbitrary 5-second delay. But this is a particular use case (not sure why one would be so concerned about fixes very close to the airport, but maybe…) For the general...

>>If a user doesn't understand that QV tabs "stick", then they will become frustrated... The same argument could be used for the 5-second timer: A user could ask "Why is it sometimes going back to ARPT?" So in your case example, you tapped somewhere on the map and selected NAV... Then you...