search

yuriknsk / tu154b

Tupolev Tu-154b airliner model for FlightGear
13 stars 15 forks source link

NVU calculation program #25

Closed DestroyFX closed 9 years ago

DestroyFX commented 9 years ago

Hi,

I want to use the NVU and also learn how it work but according to the manual, I have to take the program from Project Tupolev And it's not really usable.

Let me explain : First : it require some Microsoft Flight Simulator databases files. Second : The Jet40 Database driver in wine don't really work with that program. Third : Because of "Second", Windows is also required...

Do someone know where to find documentation of how the whole thing work so a compatible version of the program could be made or do the source exist so a port could be made?

kroki commented 9 years ago

Nope, neither MSFS nor Windows is required. What manual do you refer to? What does it say? (It may be just some bad English that made you think you have some program).

DestroyFX commented 9 years ago

That manual : http://yurik.flightgear.ru/tu154eng.html It say to use the program that come with Project Tupolev so I got project tupolev, installed it and I got these .EXE.

./project tupolev/LMTu154 B/LMTu154.exe <- ask for an aircraft.cfg ./project tupolev/MSRP/OCS_PT_154.exe <- OCS Decryptor, take 100% of the CPU when I run it ./project tupolev/NCALC FSX/ncalc.exe <- need some db file supposed to be in the FS9 folder. I found these scenery update on the net and after that I got an OLE error

I did not find any other exe file with the package.

kroki commented 9 years ago

NOTE: I made some corrections, text below may differ from what you got by e-mail.

I'm not sure what part of the doc you are reading (and it may be long outdated), but you do not have to install anything. There are some docs in https://github.com/yuriknsk/tu154b/tree/master/Docs , but somewhat outdated too and those in PT_Docs/ are foreign (from MSFS), so you shouldn't follow them literally). I once put together https://github.com/kroki/fg-navaid , but it's not required either (though I think it's handy, just checked - still works after installing required Perl modules).

Mastering NVU has quite high entry threshold, but quite easy after that. Docs/tu154eng.pdf (p.33) refers to Docs/PT_Docs/pttu154_94eng.pdf (pp.41, 84) (again, you don't have to install anything, if it says otherwise than skip over that part). Better to read Docs/tu154eng.pdf in full and at least mentioned sections from Docs/PT_Docs/pttu154_94eng.pdf (though reading it in full may also give some insights).

Some basic concepts:

My current setup prevents me from flying FG, so I didn't test the recipe below, but should work (for some values of "should" :)):

I left NVU correction topic out, you may remind me at some point later when you master the above.

Patch for FG 3.4+:

diff --git i/Dialogs/nav.xml w/Dialogs/nav.xml
index 24f6f93..0cbd3b6 100644
--- i/Dialogs/nav.xml
+++ w/Dialogs/nav.xml
@@ -78,13 +78,13 @@
           var wp0 = wpB;
           var az_corr = 0;
           for (var i = 1; fp_size > i; i += 1) {
-              var S = -wp0.leg_distance * 1.852;
-              var ZPU = wp0.leg_bearing - magvar_dep + az_corr;
+              var wp1 = fp.getWP(i);
+              var S = -wp1.leg_distance * 1.852;
+              var ZPU = wp1.leg_bearing - magvar_dep + az_corr;
               if (fork_applied)
                   ZPU += fork;
               ZPU = deg_norm(ZPU, 0, 360);

-              var wp1 = fp.getWP(i);
               var leg = {
                   from: wp0.wp_name,
                   to: wp1.wp_name,
@@ -132,7 +132,7 @@

           var vor = vors[0];
           var (b, d) = wp1.courseAndDistanceFrom(vor.lat, vor.lon);
-          b = (wp0.leg_bearing - b) / 57.2958;
+          b = (wp1.leg_bearing - b) / 57.2958;
           d *= 1.852;
           var S = -d * math.cos(b);
           var Z = d * math.sin(b);
@@ -143,7 +143,7 @@
               freq: vor.frequency / 100,
               S: S,
               Z: Z,
-              UK: deg_norm(wp0.leg_bearing, 0, 360),
+              UK: deg_norm(wp1.leg_bearing, 0, 360),
           });
       }

Thanks! :)

kroki commented 9 years ago

Ping for those who read the above in e-mail - I've made some corrections. Enjoy!

DestroyFX commented 9 years ago

Oh thanks, I will try this night.

I somehow tried to follow the outdated documentation and calculator from the original project and somehow miss the fact that it was simply in the menu..

DestroyFX commented 9 years ago

For your information, the NVU calculator window do not show in Flightgear 3.6.

I did roll back to 3.4 because I wanted to try it and it work

Edit : kroki, your instruction work perfectly! Merci!

kroki commented 9 years ago

When I tried 3.4 and used --aircraft-dir option to fgfs NVU Calculator dialog didn't appear for me too, and on console there was a message that <name> tag is required in Dialogs/nav.xml. But it does have this tag! When I used FG_AIRCRAFT environment variable instead of --aircraft-dir option the message disappeared and the dialog started to work. So missing dialog in 3.6 may be an instance of the same or similar problem (though I don't know why FG complains and how to solve this).

When someone fixes the missing dialog in 3.6 please do not forget to re-check if the patch above is required.

kroki commented 9 years ago

Above I forgot to mention that Virtual Navigator also updates latitude setting on gyros panel on the overhead, and applying the fork to gyros manually is also done using that panel (the procedure is much like when you setup gyros before the flight - PDF docs have a description of that).

NVU calculates airplane position in leg's coordinate system by continuous integration over velocity (i.e. a vector) relative to the ground, and such velocity comes from ДИСС (DISS, "Doppler ground velocity meter"). DISS panel is located in the middle "top" of the overhead. Left switch is power, middle (СУША-МОРЕ - "land"-"sea") selects between long and short wavelength radars, and the right switch (IIRC СЧИСЛЕНИЕ: ДИСС-СВС-Контроль - "calculate using: DISS-pitot-test") selects mode. Test mode is for checks on the ground - it makes DISS output fake constant ground velocity. Pitot mode disables the radar so that NVU receives only air velocity, but not ground velocity. Finally, DISS mode enables Doppler radar and is what you normally use during the flight. However in this mode the radar may not work in some situations:

When DISS radar doesn't work on the front panel yellow light память ДИСС ("DISS memory") turns on.

When DISS radar works NVU also computes wind velocity (by subtracting air velocity from ground velocity) and outputs wind heading and speed to the wind panel (which is easy to overlook, you have to switch to the view of the panel between seats and then move the view to "below"/back). Here note that when we say "north wind" we mean that wind blows from the north (ATIS also reports winds this way IIRC), but the direction on the wind panel is where the wind blows to (and heading is obviously relative to the gyros, i.e. magnetic for departure or arrival waypoints). However when DISS radar doesn't work (when "DISS memory" light is on) NVU will compute ground velocity my summing air and wind velocities taking the latter from what is "memorized" on the wind panel, and you are supposed to update wind panel manually every 15 minutes or so. In the top right corner of the front middle panel there's a speed indicator with a knob В-П ("A(ir)-G(round)") that shows either IAS or GS (when DISS radar doesn't work GS value is what is calculated by NVU).

Next post will finally be about NVU correction.

Update: remembered that there's a dial to enter azimuth correction on wind panel. This is a mere convenience. When DISS radar doesn't work you ask traffic control for the wind. But they report wind heading in their magnetic frame of reference, which may be different from departure or arrival FOR the gyros are currently in. So you may dial the correction for current location (local fork value) so that then you can input the heading exactly as reported by traffic control.

DestroyFX commented 9 years ago

Really good post, I appreciate :)

I think the doc should be updated for the NVU as currently it reference the doc for Project Tupolev for FSX. I did 4 completes flight with NVU and here are the results:

-1 : ukkk->uudd. NVU was working (I thought) and I got totally of course and on the wrong direction. took a while to reach the airport and I switched to the heading bug.

After flight 1 I have reverted the patch "diff --git i/Dialogs/nav.xml w/Dialogs/nav.xml" in kroki previous post. The three other flight without the patch was only, slightly off with is not a problem as I used ATC controlled airport so I deviated from the configured course as requested by ATC :)

flight 2 & 3 : ukkk-uudd : no problem, at all except the small deviation I have mentioned. Flight three deviated a little more (I did flip the kopp (the third switch on the NVU, bottom right) and I have added the rsbn station to my flightgear nav.dat.gz file).

flight 4 : cyqb->kiad : everything was like flight 3, just a small deviation, nothing bad. Reached kiad ATC range, started to make altitude change and course deviation for ILS approach until * The plane wanted to go to 0 degree, nothing to do. tried to reset the absu, tried manually... it was not possible to head anything not 0 degree except by doing a loop, reversing at 180 degree and the plane turned himself back to... 0 degree.. * For that last problem, I don't know if it's related to Flightgear (3.4, from Gentoo portage) or to the tu154b-model.

I made a video of the last problem to show for bug report : https://www.youtube.com/watch?v=eB5QeLst5PI I did post it on the flightgear forum too but did not get answer. Note : I must have at lease 50 hours on that plane, never got that issue until yesterday.

kroki commented 9 years ago

Above I set a clear criteria for whether the patch has to be applied:

BUG NOTE: if first leg S is zero instead of -42.5km this means you have a bug that I see now - FG people made another careless change - you have to apply the patch below

If you saw a zero first leg that should not be zero than you have to apply the patch. Otherwise you have not. You should not decide about the patch based on some other criteria like what direction you ended up flying, etc.

You also mention that you enabled NVU correction but it seems you did it wrong. I'm yet to write the instruction, but Flight Manual explicitly forbids flying with enabled correction. This however could not be the cause of the problem from your video - that I can't comment, too many things go wrong there. I think it will be more productive if instead of debugging 3.4 you invest your time in figuring out how to make NVU Calculator work in current version of FG (from what I know FG people changed XML validation, maybe that's related).

kroki commented 9 years ago

Also FYI: when I tried to create a route CYQB-KIAD FG generated last leg that is 4823.1nm long and has a vary strange protrusion to the right. cyqb-kiad

So maybe there's some bug in FG terrain data that messes up with geodesic computations, and causes the heading bug that you observed. But again, it's better to invest in current FG version.

kroki commented 9 years ago

NOTE: I decided to write about NVU correction only to realize that FG people changed not only semantics of leg_distance, but also that of leg_bearing. I didn't notice that before because I didn't fly it through, and that's why the patch didn't work for you (and without the patch you saw deviation because your route was off by one small leg). So I updated the patch above.

I also noticed that FG's Route Manager seems to always generate broken last leg, not only for CYQB-KIAD, but at least also for KSFO-KOMA.

BIG FAT UPDATE: with new FG semantics it's not quite clear what the actual value for bearing is. In general the bearing from B to A is not the reverse of the bearing from A to B. E.g. if A is at lon=0, lat=0, and B is at lon=90,lat=45 then to get from A to B in a straight line you start by moving North-East, whereas to get from B to A in a straight line you start by moving West (not South-West). Now in FG what used to be A.leg_bearing now is B.leg_bearing, but is it the same value, or the reverse of bearing from B to A? I let others look into this...

kroki commented 9 years ago

OK, finally the happy end of the NVU saga.

In the USSR a different kind of beacon was widely used instead of VOR-DME, called РСБН (RSBN, "radio system for near-range navigation", where "near" is 200-250km). In RSBN receiver you dial a channel instead of a frequency. Also unlike VOR all RSBN stations are oriented toward the true north. RSBN receiver is located in the "top" left corner on the overhead, there are two dials: 0-10-20-30-40 and 0-1-2-3-4-5-6-7-8-9, thus allowing for channels 00-49. But since there are no RSBNs outside the former USSR and East Europe (and even those are not included in FG navdata), RSBN receiver in the model allows for tuning in to VORs. To the "North-North-East" of RSBN panel there are two switches labeled РСБН: питан.|опозн.. Left switch is power, and right switch enables "VOR mode". In this mode instead of RSBN channel you dial VOR frequency (the value is hinted in the bottom left corner of the screen).

There are two data channels in RSBN: distance and azimuth (true heading from RSBN station to the aircraft). When there's no signal in the distance channel a yellow light дальн АВТОН ("autonomous distance") turns on on front panel. Same for azimuth, the light labeled азим АВТОН ("autonomous azimuth"). On the front panel next to Air-Ground speed indicator there's and instrument that shows RSBN bearing and distance (even in "VOR mode" the bearing is true).

When you fly long enough by NVU a certain positional error builds up (also there's often a starting error because the route is laid from the middle of the runway whereas you seldom enable NVU computer exactly at this point; normally you enable it just before takeoff and thus end up being off by half the runway length). So it is desirable to perform NVU corrections during the flight (at least once close to arrival).

On active NVU set top counter is labeled САМОЛЕТ ("airplane") and bottom counter is labeled МАЯК ("beacon"). On inactive NVU set bottom counter is labeled ПУНКТ ("waypoint"). The meaning of "airplane" and "waypoint" was described in previous post. To perform NVU correction we need to provide beacon coordinates in the coordinate system of the current leg, and true leg bearing (i.e. the true heading of vector originating at the RSBN station and parallel to the current leg). Coordinates go to "beacon", and heading is dialed into the instrument located next to booster switches cover on the panel between the seats. For the example (and because I can't fly with my current setup) we'll perform NVU correction on the ground. Here's how it's done (in the text below I assume you followed the steps from this post and NVU is ready for KSFO-KOMA route):

To make the correction process smooth if distance or azimuth signal is lost while the correction is turned on the yellow light will go on for the channel as said above, and NVU will compute missing value, i.e. the instrument that shows RSBN distance and azimuth will stay alive as if the signal is there (this is what "autonomous" in the light label means).

NOTE: in flight you must disable NVU autopilot mode before correction (by switching it to "heading hold mode" (СБРОС ПРОГР. button)). Also, as I mentioned earlier, Flight Manual explicitly forbids to fly with enabled correction (that is, for prolonged periods of time).

That's it!

kroki commented 9 years ago

Ah, it's also worth noting that one shouldn't trust one particular instrument during the flight (like NVU). Instead one should constantly cross-check with other means (like VOR and NDB beacons). Note that pilot's compasses by default show magnetic heading for magnetic declination as it is in departure (before fork is applied) or arrival (after fork is applied) location. When using VOR you want to switch compass to magvar of the location you currently fly over (because VORs are supposed to be oriented by it). To do so place corresponding (left or right) switch labeled КУРС-ПНП: ГПК-ГМК (on overhead panel) to bottom (ГМК) position.

Also keep in mind that while VORs are supposed to be oriented on local magvar, they aren't udated timely and magnetic field drifts away. For instance:

$ kroki-fg-navaid OAK
--
Coordinates: N37°43'33.30", W122°13'24.90" (37.7259167, -122.2235833)
Magnetic declination: E13°42' (13.70)   <= orientation should be this
Ident: OAK
Object: OAKLAND VORTAC
Elevation: 13'
Orientation: E17°00' (17.00)            <= actual orientation
Frequency: 116.8mhz (130nm)

Update: when you use VOR in place of RSBN the actual VOR orientation is taken into account as if it was an RSBN (which are always aligned with true north), so you don't have to think about magnetic vs. actual orientation difference (but you have to when using VOR navigation natively).

kroki-fg-navaid reports magnetic declination for World Magnetic Model version 2005, which is what FG used at least until I last checked in 2013. The script also supports 2010 and 2015 in case FG updates its own.

kroki commented 9 years ago

DestroyFX, I just built latest FG (3.7) from sources and NVU Calculator dialog opens for me without any problem (I also created #33 for the patch above). Could you please re-check your earlier statement?

DestroyFX commented 9 years ago

I confirm that it's not loading with 3.6 & 3.7 while it's fine with 3.4.

I now suspect that it's related to my symlink ( /usr/share/game/flightgear/Aircraft/tu154b -> /mnt/repo/plane/flightgear/tu154b ).

kroki commented 9 years ago

It may relate to symlink. Try to remove it and run with

$ FG_AIRCRAFT=/mnt/repo/plane/flightgear:$FG_ROOT/Aircraft fgfs  --aircraft=tu154b
DestroyFX commented 9 years ago

Yep, it was the symlink. Somehow it work fine with 3.4 but they managed to break that.

kroki commented 9 years ago

@DestroyFX, I think you may close this report. The patch above has been merged, and the bug in route manager doesn't relate to tu154b.

BTW I was wrong saying that our artist doesn't speak English, turned out he's more proficient than I am. He's working on other stuff at the moment, but will turn to engineer panel quite soon. git show cd19b00 for his name and e-mail if you have to get in touch with him.

DestroyFX commented 9 years ago

Yes, saving your documentation closing that :)

thlytras commented 8 years ago

For the benefit of anyone reading this thread searching for info about the NVU nav computer: my R package rfgfs (GPL, source available on github) includes functions to calculate NVU data, RSBN correction data, and do manual corrections using VOR-DME or 2 VOR/NDBs.

Admittedly I need to work a bit more on the documentation, but usage is fairly simple (at least if you use R). Here's a quick example:

library(rfgfs)
plan <- planRoute("UUDD", "UMMS")
plan <- planNVU(plan, c("UUDD","BITUL","LO","WZ","IP","UK","ASKIL","MNS"), init.mag=TRUE)
RSBNs <- corrPlanRSBN(plan)

Anyone interested can study the code of the functions to see how everything is calculated.