#2801 navselector prop rule causes [ALRT]:autopilot DigitalFilter: unknown config node:

[Huntley Palmer]

On 'next' using a model with KAP140, e.g.c172p, lancair235 the console logs these errors:

8.76 [ALRT]:autopilot  DigitalFilter: unknown config node: absolute
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value
    8.82 [ALRT]:autopilot  DigitalFilter: unknown config node: value

which are traced to the property rule file navselector.xml . The first filter in this file:

  <filter>
    <name>in-range</name>
    <type>gain</type>
    <debug>false</debug>
    <input>
      <condition>
        <equals>
          <property>instrumentation/nav-source/selector</property>
          <value>0</value>
        </equals>
      </condition>
      <property alias="../../../params/source1-in-range"/>
    </input>
    <input>
      <condition>
        <equals>
          <property>instrumentation/nav-source/selector</property>
          <value>1</value>
        </equals>
      </condition>
      <property alias="../../../params/source2-in-range"/>
    </input>
    <input>
      <condition>
        <equals>
          <property>instrumentation/nav-source/selector</property>
          <value>2</value>
        </equals>
      </condition>
      <property alias="../../../params/source3-in-range"/>
    </input>
    <value>0</value>
    <output>instrumentation/nav-source/in-range</output>
  </filter>

is traced through digitalfilter.cxx:903 :

  for( int i = 0; i < cfg.nChildren(); ++i )
  {
    SGPropertyNode_ptr child = cfg.getChild(i);
    std::string cname(child->getNameString());
    bool ok = false;
    if (!ok) ok = _implementation->configure(*child, cname, prop_root);
    if (!ok) ok = configure(*child, cname, prop_root);
    if (!ok) ok = (cname == "type");
    if (!ok) ok = (cname == "params");   // 'params' is usually used to specify parameters in PropertList files.
    if (!ok) {
      SG_LOG
      (
        SG_AUTOPILOT,
        SG_ALERT,
        "DigitalFilter: unknown config node: " << cname
      );
    }
  }

for the iteration i == 6 the cname is 'value' but the line: "configure(*child, cname, prop_root);" does not return true, resulting in the SG LOG error message.

It seems the 'value' tag is handled as a child of the 'enable' but as a child inside the 'input' tag it is not handled.

The g-forces.xml props rule, called from defaults.xml will throw a similar error on 'absolute value' tag.

These highest level console ALRT messages don't appear in 2020-3 build.

[xDraconian]

On 4/4/23 12:13 PM, Huntley Palmer wrote:

|<value>0</value> <output>instrumentation/nav-source/in-range</output>
|

|I believe that final <value>0</value> is invalid for a filter node.
I'll speculate that the intent is to treat this as the default value
when none of the input conditions are true.  Try changing it to
<input>0 to see if it resolves the issue (and without breaking
the autopilot).|

[Sascha]

Ooops, sorry, thats my fault.
xDraconian is correct. This 0 values are default inputs if no other input condition is meet.
So they should defined as <input>0</input>.
I updated my git-repo. Please test and merge into FG if all is fine.

[Huntley Palmer]

Hi !
These errors are still showing as Alert level console messages on 2024.1 fgdata c172p.
Can the default aircraft be updated to this fix ?

[Gijs]

Hi,

This has been fixed upstream in the C172P repository (last time it was only fixed in fgdata with [b1f87a], hence why the fix was overwritten when the GitHub repo was synced in [536cd5]). So it will be fixed once the C172P is synced again before the release. @stuartbuchanan, will you do it again?

[Huntley Palmer]

OK Thanks !