When this happens, does it help to visit the navigation menu and then come back?
No Jan, it remains tied to the departure runway take off end, here is the plane deliberately turned back to the 02 take off threshold from a Watsonville 02 take off, showing the retained 'glued on' 02-start non-waypoint 'destination' W4862 to 02 initial outbound leg. It is just like my earlier post.
It will join an initial leg that is a distance from the departure runway and then sequence normally.
The GPS legs displayed seem stuck on incorrect or inappropriate waypoints. It does not leave a route start waypoint.
115049 Finals for runway 08 at Salinas. F08 to 28L (the Monterey take off runway) is displayed.
115407 The to Salinas route map. 28L departure.
120405 A circular route map. The GPS and autopilot followed it perfectly.
120902 Mid route point W2205 to 08 displayed on the Salinas take off runway. Nonsensical leg label
121302 Take off, rolling on runway 08 to 08 labelled leg is now displayed. 08 will not go away.
122402 Stuck leg label 08 to 08 is displayed but the next leg is magenta on the map and is running.
122521 Route and autopilot follows a circular route perfectly but leg label is wrong cugvu to 08 instead of cugvu to w0917
122831 Leg labels keep showing to 08. Note this aircraft heading allows the visible rogue bearing line back to the destination (08?) to be seen (from the aircraft symbol to the mid-upper left).
124016 final leg labelled F02 to 08. The autopilot disconnected on the final leg. It made a recovery after a few seconds but disconncted again.
Perhaps the Palm Springs route and Thermal DME trouble is linked with the local below sea level terrain? Some Jackie Cochran airport fittings hover in mid-air.
However, I note that the GPS displays "28L", which was the takeoff runway, where the next waypoint should be.
I’ve found that trying to bend a route back on itself at Palm Springs makes the route go crazy and sometimes it will go back to the route start. The RNAV approach which curves clockwise from the west (BALDI) all the way to point up to 31 always fails near the end.
The FS2 route must not be able to cross itself without crashing.
There are uncorrected sim errors in that area too, the DME at THERMAL VORTAC gives a distance from 5 miles underground.
I couldn't get GPS route to sequence properly if an ORIG was included, it could not progress past a short 'first point' to 'first point' leg. It would join a remote starting waypoint OK. Is there a route activation step?
Apart from that it is really very nice.
There used to be a mobile world wide low resolution scenery at about ten pixels per mile about 2015/6, I did a round the world flight in the pre nav-great circle-easy-route days. Then it changed to about one pixel every ten miles and then into nothing?
New York area is more interesting. I only kept South Florida because I didn't know about Steam cancellations. It is my least used scenery.
There are too many glass cockpit spam cans, how about modifying the engines of the -500 into a lovely old -200 and giving us the Fred Flintstone autopilot? Maybe even include the rare Lufthansa -100?
Much less work than a NG or MAX.
I tried to go to the start (using the symbol on the navigation page) of a running but not activating (on GPS) route in the Monterey area and the sim died and when restarted it was in the middle of France. The GPS does not follow a route sequence and if trying to direct to a VOR on the nameless waypoint lists using its known VOR frequency, the sim crashes. The CDI definitely indicates in reverse.
Thanks again.
Aircraft position and start of route were close to
N 36.46 W 122.10
Restarted at.
1/2 way between PON and POY on the ground at Paris.
About N 048.55 E 002.10 No French Scenery or cultivation except Basel. Monterey add on in use.
Version 2.02.00.05 (20200803)
Thanks for your work improving the update.
The GPS waypoint list names are not visible and when a direct to is attempted the name field remains blank. A waypoint can be entered via a route in the sim navigation program page.
Many thanks for showing the CDI scale and making it real world value, this makes the sim much more enjoyable and usable. If you could do a revision could the enroute phase field be retained and displayed and the CDI scale placed on or near the CDI display as in the real unit.
Here 1.0 nm is indicated either side of the CDI field. Term is shown in the enroute phase window.
Unfortunately the CDI indicates in reverse. The instrument needle and GPS unit CDI display shows fly right for a right track error, guiding the plane further off course. The CDI instrument displays the From flag.
Thanks again for your hard work. It is very much appreciated.
Version 2.05.00.04 (20200731)
There are some GPS variation and CDI oddities remaining.
The VOR list still give TRUE bearings. The flight plan list and map pages show Magnetic. Yesterday 31 August, the main GPS would revert to TRUE after multiple turns, reversals and CDI scale auto changes. The manual CDI scale selection does not work.
The CDI scale selected is not displayed on the Flight Plan page, this is different from the real 530 & 430 GPS. If we are to rely on the displayed flight phase for CDI scale information can it reflect the real world values please, 5.0 nm Enroute, 1.0 nm Terminal and 0.3 nm Approach. The information given should be reliable and dependable.
Here HST is selected and displayed on the Arrow GPS and VOR2 on a chosen 084 magnetic inbound track. The track flown is 094 magnetic on the 274 radial (094 To), checked against the VOR list True bearing corrected to magnetic.
This setting displays the VOR CDI on ten degrees fly right and the GPS CDI on a setting dependent on the distance out and the auto selected CDI scale.
The VOR DME shows 1.9 nm and the GPS shows APR and a half scale deflection.
Sin 10 degrees * 1.9nm is 0.3299 nm for 1/2 scale or 0.6599 nm full scale. This is not a real world value.
The GPS distance gives a 0.6 nm scale.
The displayed CDI for ZBV ten degrees offset at 60 nm out (10 nm offset) was a 1/10 scale deflection which means the full scale deflection was 100 nm. This is an utterly useless scale, it would serve a track error of 59 degrees at (expected) 60 miles out, which is far beyond the worst navigation performance imaginable.
Can the real world only scales be used?, Garmin use them because they are practical.
Thanks again for the brilliant improvements.
Later ...Is it possible that you are mixing up the auto range selections (including 100nm) with the auto CDI (5 nm and lower) in setting up the sim GPS?
Thanks for replying, using a fast new Sony Xperia 1 phone the R 22 indicating 90/1 knots gave a measured zero wind ground speed of 91 knots at 60 fps, at 30 fps the measured ground speed was 66.7 knots when indicating 91 knots.
At 30 fps the sim response was dull and intermittent. The limited frame rate with the R 22 causes low sim performance.
I found an old forum entry about the frame rate being cut for the limited frame rate selection, the forum search seems to not work well in iOS, with Android a forum search produced many results, iOS only gave the most recent.
Documentation is largely absent for mobile, the wiki page did not mention frame rate cutting for limited frame rate selection in mobile. I had presumed that it was a limit to not greater than 60 fps computations. That may have been the original function in Aerofly.
iOS cannot display frame rates.
Thanks again.
That is a REDUCTION or a CUT, a limit is like not driving above 30 mph through the middle of town. This is more like pulling the leads off half of your spark plugs.
Here is the Tomahawk inbound to Homestead on the 055 magnetic localiser with the near runway HST VORTAC indicating 049 (true?),
Here is the Arrow overhead homestead with ZBV showing on the VOR list at 078 degrees (true?) at 59.9 nm, it should be 084 degrees magnetic.
The variation at Homested is 6.4 degrees west in January 2017. A true course plus west variation gives magnetic, All the GPS bearings were 6 degrees low. The same was seen with DHP near Miami intl.
The GPS does not indicate the CDI scale in use, it should show 5, 1 or 0.3.
Thanks for the update.
Setting frame limit on seems to reduce the frame rates to 30 fps. Is this an error, would it slow the sim down and cause malfunctions?
A change log for mobile would help, iOS cannot show frame rates. The wiki guide has no mention of 30 fps from the frame rate limit for mobile.
Eureka
With frame rate off and maxed out the phone gave 59.7 fps flying through the SFO built up area at low level.
Turn off the frame rate limit for the R 22!
I always understood the frame rate limit was a cap on not calculating the sim’s functions above 60 fps?
My Android (top) fast Sony Xperia 1 phone shows the frame rate in FS2020 so I tried two different setups.
With everything in 2020 turned down (except pixel density, I won’t compromise there!) in clear weather over the ocean with no land in sight it gave 30.14 fps.
With everything turned up and two low 50% cloud coverage layers it got 30.14 fps. Flying through the San Francisco built up area at low level it gave 30.08 fps at the lowest.
Adjusting the sim settings did not make the mobile R 22 sim run significantly faster in a (top) fast new Android phone.
From my speeds
30.14 fps is the basic FS2020 R 22 sim‘ frame rate speed.
30.14 fps/60 fps = 0.50233’
This looks like a chosen 50% simulation frame rate?
66.685 knots/91 knots = 0.73 observed simulation run speed rate.
Some wandering thoughts follow🙄
30.14 fps divided by 0.73 observed simulation run speed rate gives 41.14 frame rate/speed rate.
(41.14/60 = 0.69 or 69% of an ideal 60 fps).
0.50233’ ^0.5 = 0.709 or 71%.
Similar?
Could 'reducing the number of simulation steps' explain why in intense critical moments such as the aeroplane flare, the mobile sim seems to ignore (or need fresh slider off/on inputs) some rudder and throttle slider inputs? In real world flying nothing would have higher priority than control response fidelity (ignoring some crazy Airbus flight computer interventions).
As I mentioned before turning down FS2020 sim advanced settings made the R 22 more lively.
A more hyperactive mobile R 22 would be an enormous improvement, thanks Torsten and Jan for your attention.
Autothrottle used?
The full ILS procedure into Basel runway 33 at dusk with cultivation and the add-on airport, looks really very good. I must try it with trees, I leave trees off because of Bern.
Checked with zero wind and the sim Running the R 22 or the airspeed Indication does give a speed error.
It might be something to do with program overloading, Aerofly runs slow in excessively low performance devices. I turned off the interactive cockpit and advanced movements and got about 60.33 knots real time against 84 indicated, a small improvement. That setting also gave more reliable throttle and anti torque/rudder slider response and a much more responsive interaction with device tilt for cyclic control.
Helicopters are more prone to attitude and rotor wash effect airspeed position errors but they might be expected to produce under indication, I remember stalling a Cherokee with full flap and tons of power (don’t try this folks) and being impressed with it flying ‘at’ 40 mph (not knots), the pitot probe was pointing half way up!
My device is a three year old iPad pro, it is more powerful than cheap new iPads but it will be showing its age some time.
I tried a fast new Android Sony Xperia 1 phone using the autopilot at a steady speed flying towards a waypoint with zero wind and got exactly 66.685 knots true in real time against 91 indicated (23” m.p. at 1,300 feet).
