Feedback Strange vertical track in profile view under Windows 10
since EasyVFR 4 was released to the app stores, I upgraded on my Windows 10 PC to the latest version. When planning a flight in the Windows version, I sometimes get a rather strange vertical track in the profile view, as can be seen in the attached picture for an approach into LJPZ. As one can see on the left, the altitudes assigned to the waypoints make sense, however, the vertical track doesn't.
This behavior is limited to the Windows version, i.e. the vertical track shows up as expected, if I load the flightplan on my IPad. Also planning different flights on the IPad never resulted in such a strange vertical track, whereas planning the same flights in the Windows version do.
Does anybody have the same issues and found a workaround? Do I just miss something and it's a mistake on my end?
Thanks for any help and best regards
Thanks for reporting this, Roland. This is a known issue - at least I *thought* it was a known issue until I read that you see this ONLY in windows and NOT on your iPad. I woudl have expected you to see both behaving identically. So first I woudl like to explore whether there are actually differences between how your EasyVFR is set up on the two devices; specifically:
(1) Is the flight set up for the same date and time on both devices, with weather data downloaded at the same time on both, and with "auto-wind" set ON on the route page on both devices? Differences in the wind used in the tow devices could lead to a difference such as you are reporting.
(2) Are both devices set to use teh same aircraft profile, and are those aircraft profiles identical in all details on both devices? Any discrepancies in teh aircraft performance characteristics could likewise cause a difference such that these "odd" profiles only appear on one device.
As the code used to draw the VPV is *identical* in all platforms (Windows, Macs, Android, IOS) I am completely at a loss to understand how they could behave differently unless in some respect they are using different data.
To talk now about the underlying reason that these profiles appear, if you have previously used EasyVFR Version 3, you may recall that with Version 3, the VPV showed just "constant altitude" flight for each leg, wit a step change in altitude at each waypoint; no attempt was made to take account of aircraft climb or descent performance. In Version 4 we have instead included a depiction of climbs and descents during each leg to give a realistic flight profile while respecting the cruise heights specified for each leg between the climbs and descents. However, the aircraft profiles contain only limited information about the teh aircraft's climb and descent performance, often containing just a cruise speed and fuel consumption, and one climb speed with its climb rate and fuel consumption, and one descent speed with its descent rate and fuel consumption. In the absence of any further information, teh performance calculations ASSUME the this is the maximum climb or descent rate the aircraft can achieve, though in practice the performance points typically are NOT teh actual performance limit points because, for example, pilots very rarely choose to descent or climb at the maximum gradient that their aircraft can achieve. Typically the performance data shows just a 500 ft/min descent rate, that a pilot may often use, but (especially in mountainous areas) a pilot may be forced to use a higher descent rate. These odd profiles as in your picture indicate that the aircraft cannot achieve the height change you have specified in the distance available between the two waypoints. (Hence, if there is a difference in headwind or tailwind between the weather conditions used on your two devices, or a difference between the performance models use on the two devices, in one case the descent may be possible within the available distance (and thus show a sensible-looking profile) while on the other device is is not achievable and this is indicated by the irregular trajectory.)
We are continuing to think about the best way to resolve this issue. In the meantime, the things that you could try are either to modify the performance characteristics in the aircraft profile to provide a steeper descent condition (Note - you will need to make teh same change to teh profile in both devices, they are not synced automatically) and/or adjust your planned flight altitudes to allow a more gradual height loss as you reach your destination.
I would very much appreciate further feedback form you on this issue, both as to if you can find any differences in weather or aircraft characteristics the two devices are using, and what success you might have adjusting the planned flight altitudes and/or performance details. This will all be very useful for our considerations as to how better to deal with cases where the planned profile exceeds teh performance indicated in the aircraft profile.
thank you very much for the detailed explanations, that really helped. I ran EasyVFR 4 today side by side on Windows 10 and the IPad to compare settings. In short, the aircraft profiles were different, all other settings were the same. On Windows, I inadvertently used the default aircraft settings which had a descend rate of 500 ft/min. On the IPad I used the actual aircraft I am flying with, with a decend rate of 800 ft/min. Using the same profiles on both devices fixed the issue (as 800 ft/min is sufficient to reach the desired altitude at or before the corresponding waypoint).
At least from my point of view, a first improvement could be to make people aware what the meaning of the entry "descend rate" in the aircraft profile actually is, by re-labeling the "descend rate" to "maximum descend rate". I was not aware. I guess the same appies to the climb rate. Future releases could feature a tag in the VPV on those vertical tracks, where the descend rate needs to be increased (automatically) w.r.t. the setting in the performance tab to reach the desired altitude.
Thanks for your help
Thanks for your quick reply, Roland. I'm pleased (and relieved!) that the cause of the different behaviour has been identified!
The downside of setting the profile descent rate to 800fpm, unfortunately, is that the VPV will now always assume that you want to descend at that rate whereas perhaps if you were flying in an area without mountains you might perhaps tend to descend towards your destination at a lower rate? Perhaps we really need to be able to specify a "preferred" descent rate as well as a maximum rate (and likewise for the climb)? Alternatively I suppose that the profile could default to say 500fpm but be able to increase up the the declared maximum if the planned waypoint altitudes demand it.
But certainly making it clear that the rate entered in the aircraft profile is being taken as the maximum rate should be a very easy change that would be very helpful!