PA-28R Arrow III

To add to the above, at KCVO Corvallis Muni: NAV1 on and set to CVO (115.40) DME off No Morse ident for NAV1 Switch on DME in RMT mode Still no Morse ident for NAV1 Switch DME to FREQ mode and set to 115.40 Morse ident for NAV1 now works Switch DME back to RMT mode with FREQ mode still set to 115.40 Morse ident for NAV1 still works So Morse ident for NAV1 only works if DME is on and set to the same frequency. NAV1 Morse ident should work if DME is off (but doesn't). NAV1 Morse ident should also work if DME is on and set to another frequency (but doesn't).

@Martyn Yeah, that's understandable. You all seem to be doing the best with what MSFS provides so I can live with minor stuff like that. @sender46 When I'm flying on pilotedge I of course have the radios on, but offline there's nobody to talk to so I basically pretend I'm flying nordo (which is perfectly legal as long as you stay out of airspace which requires comms). But turning the radio on is super easy, barely an inconvenience, so I suppose it doesn't really matter.

@derek Thanks for the reply ...

@retiredman93231 I thought of the possibility of the other complex bindings possibly contributing to this behavior. So as I mentioned in my last reply yesterday this behavior persists with the Bravo and all but one other simple controller with a single two position switch powered down. I will have to check that circuit breaker though. Wouldn't it be nice if it was just that simple!! Getting back to the Arrow after installing SU7 I had another idea of what might keeping the gear lever in the cockpit from moving in response to the GEAR UP command variable. It was because I was parked on the ground! It was that simple! On all my other RG aircraft the gear lever in the cockpit would move up and down in response to GEAR UP and GEAR DOWN commands even while sitting on the ground, and that became my lazy man test to see that the switch assignments were correct without taking the time to taxi and actually takeoff. That does not work with Arrows! Once off the ground the cockpit gear lever goes up and the gear retracts in response GEAR UP command as expected. However I do not believe this behavior is truly realistic. I do not recall anything preventing the gear handle in the RL Arrow from being raised to the gear up position while on the ground. It is the squat switch is that prevents gear retraction on the ground in that aircraft, not the gear handle itself. I have read that some aircraft may actually have a mechanical linkage preventing the gear handle from being raised into the gear up position. But not the Arrow.

Further tweaks are coming very soon - https://community.justflight.com/topic/1806/update-change-logs-v0-10-0-released-edited-18-11-21/1 Hopefully the SDK will give us more options for reflections soon.

@gabe777 The Turbo was an upgrade for Arrow users and there was a bundle. No backwards discount unfortunately.

@cgnoorloos I second that. The III is my most flown plane by a long shot. I now fly entirely in VR and would like to think if I ever found myself in a PA28, I would know where everything is. I fly almost entirely by hand and never put on the Altitude hold as that is not part of the original plane.

@sender46 I see this is now included in the changelogs. Thanks Martin

@martyn in the change log I see the issue mentioned but only exterior parts shown at the end of the flight. For me it happens as soon as I see my friend with the same plane in the sim. See https://community.justflight.com/topic/2915/multiplayer-issue Will this be fixed as well? And when can we expect the update in the msfs marketplace? Thanks.

Seems to be the same as this issue: https://community.justflight.com/topic/2799/pilots-head-and-glasses-pop-into-view-randomly-after-msfs-1-20-6-0-update/9 Didn’t see that one earlier.

@martyn sorry for not replying! I updated that 3rd party gps and all was good!

The morse code idents are also difficult to hear in some of the default aircraft... so, this is more of a problem in MSFS than a specific aircraft bug.

We've not been able to reproduce this. If possible, could you provide a recording?

We haven't been able to reproduce the issue with the parking brake handle so please get in touch with our support team via a ticket if you are still encountering that so we can investigate further. Please refer to the change log thread for info on other upcoming fixes - https://community.justflight.com/topic/1806/update-change-logs-v0-9-0-released-edited-09-11-21

Unfortunately I have no experience of using FSUIPC offsets but the PA28 uses SimConnect to intercept various control events like flaps and the fuel selector and then process them using our custom code, so there might be an issue there. However nothing has changed in our code since SU6 so it'd be worth speaking to the developer of FSUIPC.

I've never used that function myself (didn't even know it existed), but there is a complaint about the same issue on Avsim. I suggest you file a zendesk request.

Found it - Apparently the profile for the stick set a double assignment to the twisting axis, one for the rudder, one for the NWS that just increases or decreases the value without auto-centring. Thanks for the help!

I've sometimes had this when I inadvertently activated pushback.