Space Shuttle - Help

[Vinny002]

Guys, I am confused now! Please help. Thanks! Cheers, Vincent.

[D-ECHO]

@Vinny: You need to answer the questions asked to you if you want to get help, particularly this one here:

Hey Vinny.
Could you provide more details ?
FG version( 2018 or 2019), What is the visual alarm on the central alarm panel associated with the aural one?
Do you have anyyhing written in the consol ? ( Debug/Nasal Consol) etc

[GinGin]

Question for reading the pfd SVG file.
I used several versions of Inkscape ( from 0.43 up to 1)

And I have that kind of superimposition of elements that are not like that in the cockpit ( or gimp)
Is it normal ?
( here example of pfd, ATT LVLH MM etc are all in the top left)

[Thorsten]

Most of the SVG stuff I have hand-written with a text editor (you get exact placement of elements when typing in numbers easier than when dragging with the mouse...)

The SVG layer basically just defines and places elements - they're translated to canvas structures (text mostly) and then made visible (or not) via canvas commands. So to the degree that elements are enabled or disabled, they will overlap in the SVG (I've never seen it, but presumably all of the DPS are one big mess in SVG).

Most of the PFD I've done by just generating elements in canvas (which is yet easier than creating an SVG in the text editor), the few elements that are not are Richards first demo of the display which I've never faded out. But it would be quite possible to discard the whole thing and do the remaining elements also in canvas directly.

[GinGin]

Ah ok !!
I didnt think to open it with a code reader like visual code.
Crystal clear now
Wow, 52000 lines

Inkscape is just good then just to have a quick look to the shapes without saving, as they are conserved as opposed to the object placement.

[GinGin]

Hello,
I am a bit blocked somewhere.

I changed a bit MM 103 for TAL ( feeding it with DAz, diversion Airport distance and HAC course)

Code: Select all

#TAL differences for MM 103 Blanked CDI/ RW range DAz HAC course

      if (getprop("/fdm/jsbsim/systems/entry_guidance/guidance-mode") == 2)
          {
          p_pfd.cdi_dots.setVisible(0);
          p_pfd.Daz.setVisible(1);
          p_pfd.bearing_HAC_H.setVisible(1);
          p_pfd.dist_to_HAC_C.setVisible(1);
          delta_az = getprop("/fdm/jsbsim/systems/entry_guidance/delta-azimuth-deg");
          hac_c_distance = p_pfd.nd_ref_rem_dist.getValue();
          bearing_HAC_H = getprop("/fdm/jsbsim/systems/entry_guidance/target-azimuth-deg");
          }


The thing is : With TAL guidance 2, entry guidance parameters are not yet fed in MM 103




If I go to RTLS guidance ( 3), it activates
Then back to 2, it stays like I would like to have first



Where can I look to change that, and have those parameters updated in MM 103 with TAL selected?

[Thorsten]

Sorry - I don't understand what you mean. Since it is possible to fly TAL without RTLS first, it stands to reason that guidance to the desired landing site is produced and handed to the AP,

So With TAL guidance 2, entry guidance parameters are not yet fed in MM 103 makes no sense to me - we're using the ballistic impact point distance to the landing site to determine MECO during a TAL and we're using the direction to determine the yawing program - so the landing site is known to the AP.

There's no entry-specific parameters computed in MM 103 yet - but that's because we don't need them at this point.

[GinGin]

Sorry - I don't understand what you mean. Since it is possible to fly TAL without RTLS first, it stands to reason that guidance to the desired landing site is produced and handed to the AP,

I tried that ( switching to guidance 2 to 3 and back to 2) to see what was the trigger to have the entry_guidance page providing datas about delta_azimuth, course, distance etc
Either mm304 or 601, but I didnt find in files where it was coded ( that was my question)

So With TAL guidance 2, entry guidance parameters are not yet fed in MM 103 makes no sense to me - we're using the ballistic impact point distance to the landing site to determine MECO during a TAL and we're using the direction to determine the yawing program - so the landing site is known to the AP.

There's no entry-specific parameters computed in MM 103 yet - but that's because we don't need them at this point.

I should have be more precise: Entry_guidance is not yet fed with relative parameters regarding the Tal site (like Daz, course etc)

And thats why I wanted to know if it was possible to trigger it for mm 103 when guidance-mode = 2
To provide the PFD with delta-azimuth ( for Runway bearing and DAz) and remaining distance for RWY while in mm 103T ( though like you said, that one might be feed by the ballistic distance.

[Thorsten]

I believe you would need to look into the launch AP program and go into the TAL section. You see there lines along

var course_tgt = shuttle_pos.course_to (SpaceShuttle.landing_site);
var dist = shuttle_pos.distance_to (SpaceShuttle.landing_site);

So the diff between current course over ground and target course would be the DAz and the distance is what you're looking for - you could simply write them into the relevant properties.

We should /not/ call the entry guidance routine needlessly, because it is much heavier than that - and we have computed course and distance anyway inside the TAL ascent, so all we need to do is use it.

[GinGin]

Thanks.
Indeed smarter and less heavy

[Thorsten]

... and the advanced exercise - if you want DAz and distance for display on the PFD, it would be faster yet not to create any property I/O at all and simply pass them via a Nasal variable (from the global AP variable space I guess...)

[GinGin]

I did like that (?)

Code: Select all

#TAL differences for MM 103 Blanked CDI/ RW range DAz DXtrk

      if (getprop("/fdm/jsbsim/systems/entry_guidance/guidance-mode") == 2)
          {
              p_pfd.cdi_dots.setVisible(0);
         p_pfd.dInc.setVisible(0);
         p_pfd.Daz.setVisible(1);
         p_pfd.bearing_rwy.setVisible(1);
         p_pfd.dist_to_rwy.setVisible(1);
         
         var shuttle_pos = geo.aircraft_position();

         delta_az = shuttle_pos.course_to (SpaceShuttle.landing_site) - yaw;
         bearing_rwy = shuttle_pos.course_to (SpaceShuttle.landing_site) - yaw;
         rwy_distance = shuttle_pos.distance_to (SpaceShuttle.landing_site) / 1853.0;
         

         if (SpaceShuttle.landing_site.rwy_sel == 0)
            {landing_site_text = SpaceShuttle.landing_site.rwy_pri;}
         else   
            {landing_site_text = SpaceShuttle.landing_site.rwy_sec;}
          }

[Thorsten]

Right - that would seem to be inside the PFD code. It requires you to do

Code: Select all

var shuttle_pos = geo.aircraft_position();

there as well (which we already had to do inside the AP) and is worth three property I/O units (because internally it works that way). This isn't a devastating hit, but they do tend to accumulate and are our largest drag of framerate.


Which is why I mentioned the elegant solution which has zero property I/O units.

(I don't know if you know that, but reading from or writing to a property from Nasal is vastly more expensive than about anything else. I believe in one benchmark test I found that one property I/O unit taskes as much time as 1000 evaluations of a sine function.)

[Hooray]

(I don't know if you know that, but reading from or writing to a property from Nasal is vastly more expensive than about anything else. I believe in one benchmark test I found that one property I/O unit taskes as much time as 1000 evaluations of a sine function.)

It should however make a difference whether props.nas is used, setprop/getprop or some dedicated mechanism (going through Nasal extension functions or cppbind).
Also, it should make a difference how property I/O is structured when dealing with indexed properties, or property names that make use of string concatenation - which is best to be avoided anyway.

Speaking in general, Nasal variables should ideally be favored over property tree state (if possible/feasible).

[amalahama]

Hi! I've been lately looking for nice orbital mechanics books, I tried to find some references in Space shuttle deluxe manual but I couldn't find any. @Thorsten, @GinGin, can you recommend some?