PT annunciation is stuck

[hbeni]

Observed: Showing steady "PT" annunciator in AP-standby when no manual electric trim input was given (no trim command issued).

Expected: Manually rotating the trim wheel without active AP should not yield a steady PT annunciator illumination. In standby the AP checks only for trim fault (trim run more than 5sec) and show this with a steady PT. The C182S POH says that can occur with a stuck MET (manual electric trim) switch, so a possible implementation could highlight PT when rotating the trim-wheel for longer than 5 secs.

Steps to reproduce: Boot up the AP on the ground and rotate the trim wheel all the way up or down, wait for 10 seconds or so. A steady PT will highlight.

[reiszner]

The problem is that the code watch the trim movement by filter the real elevator-trim to his own elevator-trim by noise-spike filter with a low max-rate-of-change. If this two props are the same, it means the trim is not moving. A difference will set a time stamp so we know when the trim starts to move (to count 5sec). I have fixed it by setting the max-rate-of-change to a high value if the AP isn't engaged. But this lead to the problem that we dont see a stucking trim switch. The filter sees only the elevator-trim, but has no clue why the elevator is moving. The AP doesn't know if you crank the wheel by hand or electrically.

Do you have a idea how we can distinguish between manual trim (mouse action in 3d cockpit) and electric trim (key [Home] and [End]) ?

[hbeni]

Observed: Showing steady "PT" annunciator in AP-standby when no manual electric trim input was given (no trim command issued).

Expected: Manually rotating the trim wheel without active AP should not yield a steady PT annunciator illumination. In standby the AP checks only for trim fault (trim run more than 5sec) and show this with a steady PT. The C182S POH says that can occur with a stuck MET (manual electric trim) switch, so a possible implementation could highlight PT when rotating the trim-wheel for longer than 5 secs.

Steps to reproduce: Boot up the AP on the ground and rotate the trim wheel all the way up or down, wait for 10 seconds or so. A steady PT will highlight.

Yes: i already implemented a filter that set a property if the trim was moving by checking the servo itself. That could easily combined with a monostable (see the over-g filter, there is one too) to get a boolean „is-moving-for-longer-than-five-secs“ property on which the logic can act.

[hbeni]

Edit: or even simpler: combine the monostable with autopilot/kap140/servo/elevator-trim-servo/clutch-engaged which signifies that the servo clutch is engaged, ie that the servo is acting.

[reiszner]

Oh, nice … if this prop is working correctly it should be very simple to react only on electric trim. Thanks for the hint!

[reiszner]

EDIT: no, its only 'true' if the AP trims but not if you trim electrically by the roker on the yoke (key [Home] and [End]).

[hbeni]

Hm. I guess the only option is then to assume electric trim like you did with the filter. When the pilot trims using the wheel, the plane should set a property, and this needs to be reset once the internal trim-filter prop reached the tgt position. If said property is set, the pt-stuck logic is to be oversteered. Result is that it’s only reacting on ap trim or electric trim.

For configuring i would propose to have these properties:

• manual-trim-engaged: property-path that will be set by manual trim movements from the trim wheel and is supposed to be reset by the ap.
• met-installed: if true, the met-stuck simulation is carried out. If false, it is disabled.

[reiszner]

I see also only 2 ways to fix it.

1) adding 2 bindings to the wheel, one 'action-binding' to set a property to 'true' and on 'action-mod-up-binding' to set the property back to 'false' as example /autopilot/kap140/sensors/manual-trim

2) re-define the [Home] and [End] key so that they additionally set and reset a property as example /autopilot/kap140/sensors/electric-trim

For the matter of holding the AP more generic and integration friendly, i think the first is better, because re-defining of the default keys can go worst. On the other side additional bindings on mouse action at the wheel is more simple.

EDIT: only one binding is needed. Looks like a knob animation can not have a 'mod-up' binding. So the property will be cleared from the kap140-propfilter.

[reiszner]

update pushed that uses method 1.

this need a additional binding in the trim wheel (c182s/Models/interior-model-c182s.xml):

            <binding>
                <command>property-assign</command>
                <property>autopilot/kap140/sensors/manual-trim</property>
                <value>1</value>
            </binding>

can you check if its also working on your side, please.

[hbeni]

It seems it does not work - the PT does never show when using this. The reason is that the sensors/pitch-trim-run is reset frequently (below 5secs) and thus never triggers here, because it gets catched up from the servo. Another (cosmetic) problem is with very rapid wheel movements, where PT is annunciated despite we had a manual trim.

Both can be adressed by simply changing the speeds slightly:

        <type>noise-spike</type>
         <max-rate-of-change>
             <condition>
                <greater-than>
                     <property>autopilot/kap140/panel/state</property>
                    <value>4</value>
                </greater-than>
                <not><property>autopilot/kap140/sensors/manual-trim</property></not>
             </condition>
-            <value>0.025</value>
+            <value>0.020</value>
         </max-rate-of-change>
-        <max-rate-of-change>1.0</max-rate-of-change>
+        <max-rate-of-change>10.0</max-rate-of-change>
         <input>controls/flight/elevator-trim</input>
         <output>autopilot/kap140/sensors/elevator-trim</output>
     </filter>

Otherwise it works fine :) merged it to the c182s (including my speeds-fix) :+1:

[reiszner]

The low value was previously 0.030, i changed it to 0.025 and it work here. But i think its a timing problem because prop-filters run with frame rate. The high value make only sure that the 5sec delay filter will not be triggered. You can set it as high as you want, it should not be lower than 1.0. Nice that it works, i will check you values.

Happy flying ;)

EDIT: works here also. Issue closed.

[hbeni]

The high value 1.0 can be faulty because when i use shift-mouewheel i could trigger the PT annunciator ;)

Thats a cosmetic corner case as i should never do that in a fight, but it was so easy to fix i would wanted to fix it nonetheless.