Numerical integration in XML gauges: is it possible?

[ilya1502]

Say, as an input I have delta heading rate and time. I'd like to perform simple integration to get the heading change. The timer starts as soon as the delta heading rate is not zero. But this is as far as I could get.

If I use this I get some crazy number which is no way near to actual heading change.

(A:DELTA HEADING RATE,radians per second) (L:TurnTime,seconds) * (L:Turn_angle,radians) + (>L:Turn_angle,radians)

If I use this I get some strange effect, which is the "Turn_angle" value increases, when I roll into a turn and then decreases, when I roll out.

(A:DELTA HEADING RATE,radians per second) (L:TurnTime,seconds) * (>L:Turn_angle,radians)

Can anyone, please, help with some ideas? I guess I have to integrate the heading rate along the turn time. How can I do this in an XML gauge?

 

[PhantomTweak]

If I use this I get some strange effect, which is the "Turn_angle" value increases, when I roll into a turn and then decreases, when I roll out.

(A:DELTA HEADING RATE,radians per second) (L:TurnTime,seconds) * (>L:Turn_angle,radians)

Correct me if I'm mistaken, but it looks to me that L: Turn_angle, radians is doing as it should. When you roll into a turn, you're increasing (AELTA HEADING RATE,radians per second), so L: Turn_angle, radians will increase.
Also, how will the gauge "know" what value to assign (L:TurnTime,seconds)? Unless someplace you assign a value to that L:Var, I can't see how it will have a value until AFTER you make a turn no?

It seems to me that you need to define a variable, before you start a turn, for just how long you desire the turn to last. If you're making a manual turn, you'd have to tell the gauge how many seconds you're going to hold the turn, somehow. If you're using the AP to change from one heading to another, you'd need to dial in the difference in headings. Like a ((current heading - target heading) * (AP's normal rate of change)) = (L:TurnTime,seconds), sort of variable, to tell the gauge what (L:TurnTime,seconds) will be.
It seems to me that once you define (L:TurnTime,seconds), either this way, or some other way, then your formula should work as you desire.
I know, this isn't in XML format, but I am just trying to give you some ideas. If you want, I can try to make it XML, though.

I think that would work, anyway. I'm probably mistaken somewhere in all that, though...
Pat☺

 

[COBS]

Say, as an input I have delta heading rate and time. I'd like to perform simple integration to get the heading change. The timer starts as soon as the delta heading rate is not zero. But this is as far as I could get.

Can anyone, please, help with some ideas? I guess I have to integrate the heading rate along the turn time. How can I do this in an XML gauge?

Possibly a different method that does not use a timer ?

(1) as soon as the delta heading rate is not zero , capture the aircraft's current instantaneous Heading and store to a fixed unique L:Var , eg;

(L: Aircraft Heading , degrees) (>L:FrozenInitialHeading , degrees)

(2) then ,

(L:FrozenInitialHeading , degrees) plus or minus (L: Aircraft Heading , degrees) (>L:InterimHeading ChangeInDegrees , degrees)

is progressive readout while turn is still happening .
(3) then ,
when turn completed and aircraft rolls to level ; as soon as the delta heading rate returns to zero ,

(L:InterimHeading ChangeInDegrees , degrees) (>L:FinalHeading ChangeInDegrees , degrees)

this readout gives the total turn arc in degrees from start of turn to completion of that turn .

In both (1) and (3) use a range trigger instead of " as soon as the delta heading rate is not zero " as the roll passes through that small range
it triggers the capture and storage of the L:Var value , whereas if you use zero it will constantly be loading a value to the storage L:Var .

Cheers
Karol
PS
the following might be useful as a turn trigger .
I use it for IFR work , 3.00 degrees per second = Standard Turn or Rate one turn .

      <Element>
          <Position X="30" Y="151"/>
            <FormattedText X="70" Y="24" Font="Tahoma" FontSize="10" LineSpacing="12" Adjust="Left" Color="#FFCC00" Bright="Yes">
              <Font FontSize="9"/>           
              <Color Value="#A1A9A6"/>           
              <String>%((A:Plane Bank Degrees, degrees) 57.3 / cos (A:DELTA HEADING RATE, degrees per second) r / abs )%!3.2f!%  %((A:Plane Bank Degrees, degrees) 57.3 / cos (A:DELTA HEADING RATE, degrees per second) r /  0 &lt; if{ '&lt;' } els{ '>' } )%!s!%
                      \n%\{fnt1}%\{clr2}%TURN  \{dplo= } / s%</String>
            </FormattedText> 
       </Element>

 

[ilya1502]

Thank you for your replies. I can see now that I could have avoided misleading you have I provided more information. This is a drawback of trying to keep your message concise.

@PhantomTweak
Yes, there is a subroutine that provides the L:TurnTime,seconds value. I just excluded it for brevity purposes. That thing works fine. I also expected that L:Turn_angle would be doing as it should, but for some reason it doesn't. I keep getting greatly exaggerated values, for instance, about 60 radians when turning only 90 degrees.

@COBS
Thanks for the idea, but I wanted to try to avoid it. See, your idea is quite obvious and would most likely work, but it assumes we have a heading value to start with.

I'm trying to model an old course-reference system which doesn't have a heading source of its own, just a manual input. It assumes you have to enter the initial value during startup and then it takes it as a reference and will keep it is accurately as possible using a gyro, correcting it automatically for the apparent drift. So it shouldn't really know about heading, otherwise I could just take the standard sim variable, but I'm trying to be as close to the idea as it gets. This is also a reason why predictive approach is not good in this case: the system cannot really know how fast or slowly the pilot will turn, it should just turn accordingly. That's why I bothered with integration of the turn rate along the turning time, but it doesn't work in the current implementation. Maybe I'm going the wrong way?