Project Fokker F-28 GPS navigation?

[ejoiner 21]

Hi guys, am assuming others are flying this glorious bird besides me! I have really enjoyed it, except for one problem. I find that when I plot a flight plan into my RXP GNS530 GPS (I know...non standard equipment), when I get to a VOR waypoint, the Autopilot kicks off of its VOR track. I cant get it to go to the next waypoint without manually reactivating it. Whats the best way to make it track? Granted its an older plane and this probably isnt how it was designed, but I figured to give it a better autopilot than the lousy GPS 500 from FS9.Eric

[tanker 15]

Hi Eric,I've also had some problems getting the F-28 to track a GPS course. You might try using the keyboard input (Ctrl+N) instead of just pushing the VOR button. This worked for me on my last flight. I can't imagine why it would make a difference unless there is something different in the way the autopilot gauge is programmed.Dale

[rcbarend 37]

Hi Eric, DalePlease read the F28-Support section for solution.(= remove the VORHoldCorret gauge from the panel).Background (if you're interrested):A real-world pilot informed me the NAVHold function (at least for these types of older aircraft) isn't implemented correctly in FS9.When following a VOR radial in NAVHold mode and approaching the VOR station, the aircraft should just fly over the VOR and then proceed on the same radial (but now away from the VOR).FS9 doesn't do this: when the aircraft is passes the VOR (the CDI needle drops away), it disconnect NAVHold. And when you manually reactivate NAV-hold again, the aircraft "zigzags" a lot to find the course again.I solved this problem in this VORHoldCorrect gauge, by disconnecting NAVHold just before the VOR (when the CDI needle is still valid), fly on HeadingHold over the VOR, and then reactivate NAVHold again after the aircraft is exactly on the radial again. Which works quite good..However, I never tested this last-minute feature with a flightplan in the GPS :-).Unfortunately, the GPS gauges (default or other) seem to "think" that when the NAVHold is set OFF before the CDI-needle is lost, that the pilot deactivated NAVhold... And therefore stops following to track to the next VOR.Just remove the VORHoldCorrect gauge from the panel, and your problem is gone (then VORHold is just the standard FS9 NAVHold function).Cheers, Rob Barendregt

[tanker 15]

Thanks Rob,I also have a question on altitude hold - (I realize this is a altitude hold for present altitude, not an altitude capture).When I level out manually and press the altitude hold button, the alt light comes on, but the aircraft begins to climb or descend. If I use the keyboard input Ctrl+Z, the alt light comes on and the aircraft holds the level perfectly. It's a minor problem, but I'm curious as to the cause.I should mention I am also using AV6, Radar Contact 4, FSNAV, plus FSUIPC 3.7.2.Dale

[ejoiner 21]

Thanks Rob, I think I will comment the gauge out and test it to see how that works.Eric

[rcbarend 37]

Hi Dale,I guess what happens is the following:Because I implemented I VSHold function (like the real F28) I could not use the standard FS function "Current Altitude Hold".However, what the standard FS function does (if you use CNTR+Z): it sets the FS-internal AltitudeSelector to the current Altitude (rounded to the nearest multiple of 100 ft).My gauge does the same, but it rounds to the lowest (not the nearest) multiple of 100 ft.So if your altitude is 3095 ft, it rounds to 3000.Can you confirm this is happening ??This little "oversight" is easily corrected (it already is) and we will release that in a update. Don't know when yet.Cheers, Rob

[el_kab0ng 29]

>Hi Dale,>>I guess what happens is the following:>Because I implemented I VSHold function (like the real F28) I>could not use the standard FS function "Current Altitude >Hold".>>However, what the standard FS function does (if you use>CNTR+Z): it sets the FS-internal AltitudeSelector to the>current Altitude (rounded to the nearest multiple of 100 ft).>My gauge does the same, but it rounds to the lowest (not the>nearest) multiple of 100 ft.>So if your altitude is 3095 ft, it rounds to 3000.>Can you confirm this is happening ??>>This little "oversight" is easily corrected (it already is)>and we will release that in a update. Don't know when yet.>>Cheers, RobThis same exact thing is happening to me. Oddly enough it worked fine during the tutorial, but any random flight using any of the models increases altitude by at least 500 feet. (ATC yells at me when it gets to 300+, so I usually just kick off the ALT button and attempt to acquire a 0 VSI and turn the VSI hold button on.)

[rcbarend 37]

Hi guys,I suddenly realise why this problem occurs, and why there's a difference between initiating altitude hold via my AltHold gauge and via Control-Z .Now, IF I'm right, there are two problems:- My AltHold gauge isn't logical; that is: it has a different view on what "altitude" is, compared to the standard FS9 implementation. (I don't know which one is more like the real world, by the way)- You aren't good pilots (no offence intended :-) ). See below.I guess you are using some kind of real weather, that sets the barometic pressure to another value then the default 29.92. Right ?Iow: if you compare the Altitude given by the AltMeter with the real altitude (in the FS9 info lines visible after "ZZ"), these are different.Now, the difference between between AltHold via Control-Z and my AltHold gauge is:- Control-Z sets current baro altitude as the altitude to be maintained (ie. the altitude you are flying at).- My AltHold gauge set the AP to hold the real altitude, but the FS9 AltHold function interprets this value as baro altitude.Hence my gauge code isn't very logical ....However, good pilots always keep their AltMeter calibrated...lol(in the F28 Altmeter: the small left calibration knob)If you would do that, AltHold works OK and you wouldn't have seen this problem caused by my illogical gauge code.Is all of the above correct ????I will change my AltHold gauge in an update, because, as said, my gauge code is't logical.In the mean time, make sure either you keep your AltMeter calibrated or use Control-Z only to activate Altitude Hold.Best regards, Rob Barendregt

[tanker 15]

>Hi Dale,>>I guess what happens is the following:>Because I implemented I VSHold function (like the real F28) I>could not use the standard FS function "Current Altitude >Hold".>>However, what the standard FS function does (if you use>CNTR+Z): it sets the FS-internal AltitudeSelector to the>current Altitude (rounded to the nearest multiple of 100 ft).>My gauge does the same, but it rounds to the lowest (not the>nearest) multiple of 100 ft.>So if your altitude is 3095 ft, it rounds to 3000.>Can you confirm this is happening ??>>This little "oversight" is easily corrected (it already is)>and we will release that in a update. Don't know when yet.>>Cheers, RobHi Rob,I did some further testing with clear weather, no RC4 or FSNAV. My results were mixed - sometimes it would climb a few hundred feet above the current altitude, then descend below it and gradually settle on the correct altitude. At other times it would climb or descend as much as 500 ft from the current altitude. Each time I did my best to trim for level flight at the desired altitude before selcting the ALT switch.The only consistent data I found was that if I leveled following a climb, selecting the ALT switch would result in an immediate climb. Approaching level from a descent, selecting the ALT switch would always result in an immediate descent.As a point of reference, the KC-135A I flew in the 70's had a similar autopilot and selecting atitude hold would immediately hold the current altitude so long as the vertical velocity was less than 300 fpm. Even at 500 fpm, it would work, but made for a bumpy ride.Regardless, thanks again for a great freeware aircraft and panel. I programmed a switch on my CH Throttle Quadrant to input CTRL+z, so now I just level and flip the switch just like the real thing.Dale

[rcbarend 37]

Hi Dale,See post below...Can you confirm that this is the problem ??Cheers, Rob

[tanker 15]

>Hi Dale,>>See post below...>Can you confirm that this is the problem ??>>Cheers, RobHi Rob,Did some more tests:F28 4000 NLM Cityhopper, 50% in each wing tank, Center emptyDeparted KDAY, clear weather, altimeter 29.92, climbed to 5000 ft, all tests performed at 240kias, clean configurationTest 1 level at 5000 ft, engaged ALTAircraft climbed to 5150, then descended to 5000Test 2 Disengaged ALT, releveled at 5000Aircraft desended to 4880Test 3 Descend to 4000ALT resulted in 3900Test 4 Climb to 5000ALT resulted in 4900Test 5 climb to 5010ALT resulted in 5000Test 6 reset altimeter to 30.00, leveled to 5000 indicatedALT resulted in 4900Test 7 reset altimeter to 30.27, leveled to 5000 indicatedALT resulted in 4660Test 8 reset altimeter to 29.68, leveled to 5000 indicatedALT resulted in 5200Test 9 reset altimeter to 29.92, leveled at 5000 indicatedALT resulted in climb to 5400, then settled to 5200As you can see, the results are somewhat inconsistent. In general, if I leveled a few feet above the target altitude, ALT would result in the aircraft settling at target altitude. In all cases, I tried to limit the vertical velocity to 200 fpm or less when I engaged the ALT, however I'm sure my flying introduced some variance.It does appear that incorrect barometer settings do have an effect. I should have tested what happens above FL 180 when the barometric pressure is high or low, but the altimeter is set to std (29.92) as required in the US.Hope this helps,Dale

[el_kab0ng 29]

>Hi guys,>>I suddenly realise why this problem occurs, and why there's a>difference between initiating altitude hold via my AltHold>gauge and via Control-Z .>Now, IF I'm right, there are two problems:>- My AltHold gauge isn't logical; that is: it has a different>view on what "altitude" is, compared to the standard FS9>implementation. (I don't know which one is more like the real>world, by the way)>- You aren't good pilots (no offence intended :-) ). See>below.>>I guess you are using some kind of real weather, that sets the>barometic pressure to another value then the default 29.92.>Right ?>Iow: if you compare the Altitude given by the AltMeter with>the real altitude (in the FS9 info lines visible after "ZZ"),>these are different.>>Now, the difference between between AltHold via Control-Z and>my AltHold gauge is:>- Control-Z sets current baro altitude as the altitude to be>maintained (ie. the altitude you are flying at).>- My AltHold gauge set the AP to hold the real altitude, but>the FS9 AltHold function interprets this value as baro>altitude.>Hence my gauge code isn't very logical ....>>However, good pilots always keep their AltMeter>calibrated...lol>(in the F28 Altmeter: the small left calibration knob)>If you would do that, AltHold works OK and you wouldn't have>seen this problem caused by my illogical gauge code.>>Is all of the above correct ????>>I will change my AltHold gauge in an update, because, as said,>my gauge code is't logical.>In the mean time, make sure either you keep your AltMeter>calibrated or use Control-Z only to activate Altitude Hold.>>Best regards, Rob Barendregt>The problem I see here is based on the tutorial.Once at 18k/ft, one is expected to engage the QTH/STD button for proper baro. Has anyone else noticed this adjusts the baro to 29.91 and not 29.92?In any case, even adjusting using the keyboard B option, the ALT still rises 500 feet above assigned altitude regardless of whether I've levelled off first or engaged ALT from an ascent.

[rcbarend 37]

Hi Dale,I have done some further testing myself:There are three things that you should take into account.1. If your barometer setting is not correct:This will lead to a large deviation when you activate AltHold via the gauge instead of via Control-Z.As explaned in post #7This will be repaired in an update.2. If your barometer setting is correct: A deviation of max 100 ft between using AltHold clicking and Control-Z is possible, due to the rounding. This will also be repaired.1. and 2. will be modified in such a way that there won't be a difference between using COntrol-Z and clicking my AltHold gauge.3. Now, which altitude is held if you are in a climb or in a descent when you click Control-Z ??FS9 sets the altiude to be held as the Current altitude at the moment of activation (rounded to a multiple of 100 feet). This means that if you are in a descent or climb when giving Control-Z, the aircraft may under/overshoot the target value for a few hunderd feet (depending on the V/S at activation) before it returns to the target value: the (rounded) altitude at activation time.This is standard FS9 behaviour, which I will not change.In short: after we have released an update, clicking AltHold will do exactly the same as given the FS9 Control-Z command. In the meantime, just use Control-Z, or make sure your Altmeter is set to the correct baro pressure (by using the default "B" command). Best regards, Rob PS: To make it even more complex :-):If you fly on V/S-Hold and then change want to change to AltHold via Control-Z, you have to give the Control-Z twice.Reason: FS9 has NO standard function for V/SHold. I simulated this in the VSHold gauge, by setting AltHold ON with extreme values in the (FS-Internal) AltitudeSelector. So if it's flying on my V/S Hold, the first Control-Z switch VS-Hold Off, and the second switches AltHold ON.In fact, implementing VSHold in a gauge was the reason for these AltHold problems in the first place. I just didn't implement it correctly :-)

[tanker 15]

Hi Rob,Thanks for the explanation. It gives us an understanding of how complex programming for FS9 can be when you try to imitate actual aircraft functions.When you are finished with the F-28 update, I hope you and the Project Fokker Team will consider doing a F-27 or F-50. There is a Dreamwings F-50, but I have never been able to get the recommended panel to work without CTD's (I've tried all the fixes). Turboprops are a challenge in FS9, but I'm betting your team can do a first-rate job.Dale