FSXA ETE Profile Display

[delivery guy]

I am having trouble and not sure why i can't subtract the VSR reading from the Profile setting as the total time then subtract the VSR reading from that total??? I used seconds only to cut down the code size.
Any help would be awesome....


VSR = Vertical Speed required display window in feet per minute.
PRFL = Settable profile input (Feet per minute)

Trying to create an ETE clock that estimates the time the VSR reading reaches the PRFL setting! And continues to count down to zero...

<!-- TARGET ETE -->
(L:TARGET PRFL CALC,feet) 99 >= if{

    (L:TARGET PRFL CALC,feet) 60 / (>L:TARGET PRFL MIN,Seconds)
    (L:VSR DISPLAY PLUS,feet) 60 / (>L:TARGET VSR MIN,Seconds)

<!-- ETE TOTAL -->
     (L:TARGET VSR MIN,Seconds) (L:TARGET PRFL MIN,Seconds) - (>L:TIME TOTAL,Seconds)

<!-- ETE CALC DISPLAY -->
    (A:Absolute time, seconds) (L:TIME TOTAL,Seconds) - (>L:TIME DISPLAY,Seconds) }

(L:TARGET PRFL CALC,feet) 99 &lt; if{ 0 (>L:TIME DISPLAY,Seconds) }


STRING......................

<String>
%((A:GPS IS ACTIVE WAY POINT, bool))
%{if}
%( (L:TIME DISPLAY,Seconds) abs 60 / flr 99 min )%!02d!:
%( (L:TIME DISPLAY,Seconds) abs flr 2 % 0 == )%!02d!:
%( (L:TIME DISPLAY,Seconds) abs 60 % flr )%!02d!
%{else}__:__:__%{end}
</String>

I also tried these....
1.
<!-- ETE CALC DISPLAY -->
(L:TIME TOTAL,Seconds) (L:TARGET VSR MIN,Seconds) - (>L:TIME DISPLAY,Seconds) }
2.
<!-- ETE CALC DISPLAY -->
(L:TIME TOTAL,Seconds) (L:TARGET VSR MIN,Seconds) - abs (>L:TIME DISPLAY,Seconds) }

 

[rpmc]

For starters, try (P:Absolute time, seconds) because (A:Absolute time, seconds) doesn't exist. But it doesn't look like that will solve all the problems. The 'feet' units in

(L:TARGET PRFL CALC,feet) and (L:VSR DISPLAY PLUS,feet)

don't appear to match your rate (feet per minute) description, above. That's part of the reason your math is hard to follow.

 

[delivery guy]

I actually did try both both P: and A: I will keep this in mind A: does not work.
The units are converted from feet to seconds. The reason it's feet is because the VSR uses feet up to the last display code in Feet per minute.

 

[delivery guy]

Update! I found out why i was having weird results. The VSR and PRFL were not the correct value although they are for their other specific job.
I ran each value straight through the display window and calibrated them so 100 FPM = 1:00 minute.

Now i will see what happens when i try to subtract values...

 

[delivery guy]

Cool deal, my logic was good, the borrowed values were not. Now thew values are subtracting but not with accuracy.

Now I need formula that will add estimation time...

 

[COBS]

Might be worth trying a different method.
Personally I would not use this "(P:Absolute time, seconds)" it's not necessary , and it only complicates the issue.

See below code ( Defining and declaring TIME ) ,
Just do a division , then multiply your answer by 3600 that gives you a result in seconds .
force that into a L:Variable as follows (> L:YOUR ETE,seconds)

Then use that ( L:YOUR ETE,seconds) in your TIME readout code .

It really is much simpler.

Cheers
Karol

<!--Defining and declaring TIME  To/From  Mark Position  Invisible colour-->         
            <Element>
              <Position X="1" Y="1"/>
              <Text X="1" Y="1" Bright="Yes" Length="3" Font="Arial" Color="0x000000" Adjust="Center" VerticalAdjust="Center" Multiline="No" Fixed="No">
                <String>%((L:DistanceMarkPos,nmiles) (A:GROUND VELOCITY, knots) / 3600 * (&gt; L:MARK ETE,seconds))%!02d!%</String>
              </Text>
            </Element>

<!--ON condition TEXT display-->
       <Element>
          <Position X="7" Y="19"/>
            <FormattedText X="81" Y="125" Font="Tahoma" FontSize="11" LineSpacing="11" Adjust="Left" Color="#2F912F" Bright="Yes">
              <String>

                     \n%((L:MARK ETE,seconds) 3600 % 60 / int flr 60 %)%!02d! : %((L:MARK ETE,seconds) 60 % int flr 60 %)%!02d!%
                
                    </String>
          </FormattedText>
       </Element>

(EDIT) :-
Possibly something along these lines ,

<!-- TARGET ETE -->
(L:TARGET PRFL CALC,feet per second) 99 >= if{


(L:TARGET PRFL CALC,feet per second) (L:VSR DISPLAY PLUS,feet per second) / 3600 * (&gt;L:YOUR ETE,seconds)
99 (L:YOUR ETE,seconds) - (> L:COUNTDOWN REMAINING ETE,seconds)  }

<!-- TARGET ETE READOUT TEXT BASED ON -->
(L:YOUR ETE,seconds)
<!-- AND OR -->
(L:COUNTDOWN REMAINING ETE,seconds)

 

[delivery guy]

I did remove the Absolute time because it seems like its only good for timers, clocks and for time going up, but makes no sense to use in this calculation since it's going down.
I am going to give your formula a try tonight.

Quick question! How do you make a count down timer like on a microwave?
This might help me!

Thanks karol...


P.S. I am using feet now and not seconds. So i will convert as well.

 

[delivery guy]

A few tests did not work, now I am trying another method. See what you think Karol.

ALTITUDE / FPM = TIME

TIME X KTS / 60 = NM OUT

NM OUT - (A:GPS WP DISTANCE, Nmile) = TOP OF DESCENT...

i use a test screen to show each L var and it seems that the NM out display window shows 0.....

<!-- ETE DISPLAY -->

<!-- ETE VALUES -->
    (A:GPS WP DISTANCE,Nmile) (>L:GPS WP DISTANCE,Minutes)
    (L:TARGET PRFL CALC,feet) (>L:TARGET PRFL CALC, Feet per minute)


<!-- ETE CALC -->
    (A:PLANE ALTITUDE,feet) (L:TARGET PRFL CALC, Feet per minute) / (>L:TARGET TIME, Minutes)

     (L:TARGET TIME, Minutes) (A:AIRSPEED INDICATED, Knots) * 60 / (>L:TIME, Minutes)

    (L:GPS WP DISTANCE, Feet) (L:TIME, Minutes) - (>L:NM OUT, Minutes)


<!-- ETE DISPLAY -->
     (L:NM OUT, Minutes) (>L:ETE PRFL TIME, Minutes)

 

[delivery guy]

Worked the bugs out and corrected the tags....

<!-- ETE DISPLAY -->

<!-- PROFILE CONVERT -->
    (L:TARGET PRFL CALC,feet) - (>L:TARGET PRFL CALC, Feet per minute)

<!-- ALT CONVERT -->
    (A:INDICATED ALTITUDE,feet) (A:GPS WP NEXT ALT,feet) - (>L:PLANE ALTITUDE,feet)

<!-- TIME -->
    (L:PLANE ALTITUDE,feet) (L:TARGET PRFL CALC, Feet per minute) / - (>L:TIME, Minutes)

<!-- NM OUT -->
     (L:TIME, Minutes) (A:AIRSPEED INDICATED, Knots) * 60 / (>L:NM OUT, Nmile)

<!-- TOP OF DESCENT -->
    (A:GPS WP DISTANCE,Nmile) (L:NM OUT, Nmile) - (>L:TOD, Minutes)

<!-- ETE TOD DISPLAY -->
     (L:TOD, Minutes) (>L:ETE PRFL TIME, Minutes)

 

[COBS]

I'm glad you got it to work , I presume that the countdown works.
It looks like you have the correct units in your calculations.

I had been thinking if there was another way to do the calculations , but ended up
with my earlier line being the best explanation , and was about to post a reply .

<String>%((L:DistanceMarkPos,nmiles) (A:GROUND VELOCITY, knots) / 3600 * (&gt; L:MARK ETE,seconds))%!02d!%</String>
</String>

That calculation
ListanceMarkPos,nmiles divided by A:GROUND VELOCITY, knots gives an answer in HOURS (time)
HOURS multiplied by 3600 = SECONDS

then
if
ListanceMarkPos,nmiles is Decreasing the readout is a countdown (like your microwave)
if
ListanceMarkPos,nmiles is increasing the readout is a countup (like a normal clock)

I used that code in the Mark Position instrument , if you copied and loaded that instrument ,
then you see it countdown as you fly towards the Mark Position , then countup as you fly
over and away from it.

Cheers
Karol

 

[delivery guy]

The ETE code above works like it should but does not stay in sink with the profile setting. So i wrote another code that takes the difference between the profile and the VSR and convert that into seconds. Then I add another factor using distance for a ratio to add more time for further out and a smaller ratio for closer. This allows me to tune the ratio to run at the speed of time and the most important is it always hits zero when the VSR has reached TOD. I found that the default ETE was more sporadic than this TOD ETE...

I have learned a few things this week and one was that you can have your test window showing what your results are for every line of code while getting good results quickly!
And your not working blind. Oh and I found that reversing ratios can be done by dividing. Can't wait to hear some feedback on how well this system works. karol if you want a copy of
my VSR template I have 2 versions. 1 for no MSL just a working VSR for waypoints. And another ready for both AGL and MSL. Of course they are not the entire GPS VNAV system but a good template to build your own VNAV.

 

[COBS]

That looks really nice , congratulations on getting it to work as you required .
I am constantly amazed at what can be achieved in instruments.

Thank you for the offer , but I think I will stay away from VNAV for the time being ,
a couple of other instruments are keeping me occupied well beyond my abilities.

What is your "test window" ?
I have had Black box and another recommended , but have avoided them because I assume
that there is a long learning curve associated with them .
Did it take you long to learn to operate your "test window" ?

Cheers
Karol

 

[BaiterOne]

Hi

The gauges I develop are nothing like the instruments I have seen others develop here in the forum - wow, are they complicated! - but I have always needed insight into what was happening behind the scenes in the simple instruments I was playing with because I am prone to code errors, rash assumptions and typos.

This Clipboard (bottom right) has been my lifesaver on many occasions.

My 'Co-pilot' notes things like V1,VR,V2, Fuel required etc. on various pages of the clipboard so that I can refer easily to them in flight.

It has a spare page which I use for noting the values in L Vars etc that don't actually appear on the screen but influence whatever instrument I am working on.

It only takes a few minutes to insert the L Vars and their values on the page - it holds up to 23 lines.

The number of times a var contained a 1 when I believed it should contain a 0, or that a variable is increasing rather than decreasing, is incredible, but at least I can see the value on the page and fix it.

Then when I fix it I can then see ricocheting errors!!

Walter

 

[delivery guy]

Hi Walter. Your test window look nice and I like those sunglasses on the dash. I made mine large and stacked it so you can work the math down to the bottom. Then I make copy's for other formulas and plug in the L Vars. Another good lesson I learned was to have a text file on your desktop with all of your "LABELS" for long codes. This way you can copy an L Var then use the find option to go through all of those L Vars or labels to get around the long code with ease.

Karol, glad you have some other challenges already in the making. Here is what my test window looks like. And here is the recipe for the ETE for distance between the VSR
and the Profile setting. Not perfect but does the job and is pretty dang good...

<!-- ETE DISPLAY -->
<!-- RATE -->
    (A:GPS WP DISTANCE, Nmile) sqr (>L:CALC, Number)

    (A:GPS WP DISTANCE, Nmile) sqr 3.7 * (>L:CALC2, Number)

    (L:CALC2, Number) (L:CALC, Number) / (>L:CALC3, Number)

    (L:CALC3, Number) (L:TIME, Seconds) 1.5 / * (>L:RATE, Number)

<!-- ABOVE/BELOW WP -->
<!-- SUBTRACT PRFL/VSR TIME CALC -->
(L:WP ALT ERROR,Enum) 0 == (L:MSL ALT ERROR,Enum) 0 == or if{
    (L:TARGET PRFL CALC, Feet per minute) (L:VSR DISPLAY PLUS, Feet per minute) - - (>L:TIME, Seconds) }
(L:WP ALT ERROR,Enum) 1 == (L:MSL ALT ERROR,Enum) 1 == or if{
    (L:TARGET PRFL CALC, Feet per minute) (L:VSR DISPLAY MINUS, Feet per minute) - - (>L:TIME, Seconds) }

<!-- RATE/TIME CALC DISPLAY -->
    (L:TIME, Seconds) (L:RATE, Number) + (>L:ETE PRFL TIME, Seconds)

<!-- SET TO ZERO -->
    (L:ETE PRFL TIME, Seconds) 0 &lt; if{ 000000 (>L:ETE PRFL TIME, Seconds) }

 

[taguilo]

Personally I use my own LVars logger, which will be included in XMLTool, a module I'll be releasing soon.
As it is in fact a 2D subpanel, it can be added to any aircraft panel:

Tom

 

[delivery guy]

I see you can filter to the L Vars you want to see the value for....I like this Tom!
Does it auto find all of your L Vars or do you add them for each project?

 

[taguilo]

It does auto load all of the LVars present in the current flight, not only in gauges but within the .mdl file
You can sort the entire varset, apply a filter, select those vars you want to close inspect and change their values and/or units.

And the most important, you can add/delete LVars to your XML source, set the LVars visibility mode as Global, reload the aircraft and get the same values you had before the reload. Something similar to what RELOAD_PANELS does in FS9.

Tom

 

[delivery guy]

I like that...general question! Is there any way to reload aircraft without reloading the aircraft to update your work or is this a must?

 

[COBS]

I like that Tom , it would be handy for long pieces of code.

I tend to operate in chaos , I've never planned an instrument , Fr Bill suggested using flow charts ,
and while I agree it's a good idea , I find that an idea pops into my mind and the next thing is
I create a bare bones instrument , at that stage expansion ideas flood into your mind and you
refine it , it tends to grow of it's own volition.
I tend to do it all in my head , at times I wish that I had written notes , but I'm not very
organised.
When I do calculations they tend to be on scraps of paper and they always seem to get lost.

With your arrangement screenshots would aid subsequent analysis .
In the shot below the instrument top left has a grey area , by clicking on it I get 3 pages
of data , either full strings or individual parameters , some of that data is progressive debugs or
attempts to see why something is not working as you desire it to.
Eventually the grey area will contain pertinent and fully functional data.

Additionally I do all my development in that panel , it contains a hell of a lot of of data that
helps both evaluation and calibration during the evolution process.

Your logger seems a much better solution , I just might be forced to take the plunge as some
of the stuff I'm attempting is awefully complex to understand.

Cheers
Karol

 

[taguilo]

Is there any way to reload aircraft without reloading the aircraft to update your work or is this a must?

Yes, there is a way. In LVars logger pics, on the title's bar to the right you'll see a yellow square with R inside. When you click there it triggers the RELOAD_USER_AIRCRAFT event, which makes a faster reload than doing the same through a menu option.

I tend to operate in chaos , I've never planned an instrument , Fr Bill suggested using flow charts ,
and while I agree it's a good idea , I find that an idea pops into my mind and the next thing is
I create a bare bones instrument , at that stage expansion ideas flood into your mind and you
refine it , it tends to grow of it's own volition.

Karol, I've bee working with computer software for the last 25 years and I have never used a flow chart either.

As a general idea, in my company we develope a project by first identifying the general aspects that need to be covered, then we define the different sections to be included, then each section is programmed like a whole part, with "loose ends" that have to be tied upon the final stages.

While a part is being programmed new ideas might rise that belong to other part(s) of the project, in these cases they are sketched within the proper section(s) so we can resume working on them as we get full involved with that section's (part) code.


Tom