c172p detailed

external: index
internal: comments history stunning fleet circuits other ... end


Just a personal blog type page, mainly about the new c172p (detailed) default aircraft...

20150814: FG is still in the 3.6 release cycle, but moved on my Ubuntu and Windows builds to the ongoing 'next' 3.7. Now all the latest 3.6 'c172p-detailed' have been merged to this 'next' fgdata...

Do I like the new default panel? Well, the gray background is fine, but seems quite hard to read without adding 'Instrument Lighting'... but my eyesight is not as good as it was... so maybe just me... And it comes with a considerable selection of liveries, so you can choose what colors you like...

panel dark panel lit

Read somewhere there continued to be an mp 'visability' one to the other problem, so GA006 and GA007 did some circuits of YGIL for fun together, and included a little like formation flying... both using mpserver01...

The Circuit: Runway 26 - Left 
YGIL circuit
26 Left TR 148.568577562909,-31.6935282117602 cross TL 148.566075592217,-31.7285381387937 downwind BL 148.703396619553,-31.7357054470166 base BR 148.705898782855,-31.7006955593952 final 26

This circuit is generated as a function of my FindAP (Find airport by ICAO) perl script when output as XG(raph) file is requested. It uses the runway length, and calculates a 3 degree glide path given an altitude of 1,000 feet, and aircraft speed of 100 knots. It can do this for any airport ICAO in FG apt.dat.gz (v3.7), but it gets quite messy when multiple parallel runways are involved.

The aircraft were on autopilot, and directed via a telnet connection using my do-square script. It reads the above XG(raph) file to establish the circuits, establishes a telnet connection to the fgfs instance, waits for engine, and autopilot altitude hold to be engaged, then on a 'c' key will fly the aircraft around the circuit, trying to take good account of the wind speed and direction... always a WIP... given a wind component like -w 360@8 the distance script will output an XG(raph) showing the vector 'triangle', with the 'computed' heading.

Just using the respective manual throttle setting, was able to catch up and fly with the other circling aircraft, to get the following images...

A GA007 perspective (Windows 7 32-bit) looking at GA006
circult 1 circult 2 circult 3

It is noted, with pleasure, that in the 3rd image, the fact that when GA006 shut down its engine and turned off its lights, is correctly reflected over mp ;\))

A GA006 perspective (Ubuntu 14.04 64-bit) looking at GA007
circult 4 circult 5 circult 6 circult 7

A very nice fun fly-in at YGIL... who probably saw more aircraft in one day than they usually see in a year ;=))


More History...

We are headed for a new release of 3.6, which will include the c172p-detailed, relabelled to default c172p. Important release date to keep in mind is Dec/Jun 17th: Development stream is declared "frozen" or "yellow". Already some of the c172p-detailed has been merged into fgdata master. Not sure about the schedule of these 'merges'... so the balance is pending the next merge... but see below for last update...

If you really want to wing it, get the latest git from https://github.com/Juanvvc/c172p-detailed . I just cloned it into say "D:\Projects\Aircrafts\c172p" and pointed --fg-aircraft=<at same>, sometimes moving the <fgroot>/Aircarft/c172p to a temporary storage, to make sure the very latest is selected, and then you can fly it in 3.5 sg/fg...

20150706: Note that c172p-detailed was merged into fgdata, so that is also now quite up-to-date...


Stunning stuff:

Cockpit : Most impressive change...

New Old
New cabin Old cabin

Amazing difference ;=)) Lots more breakers evident... new Alt and Battery ON/OFF, and primer... and Cabin Heat and Air. Not sure I like the duller yellow, more cream, and the brown instead of bright red, but it is ok. I can not seem to find my callsign on the new dash ... seemed to remember somethng about it was not needed... well, not needed or not, it seemed a nice touch to remind me I had assigned a callsign for mp connections... And what's this about "No Smoking". It is very much allowed in my private fleet, of course always with caution...

While both were usually much brighter in the sun than when shaded, but now the heading bug has become harder to see (in the shade). Sometimes I keep the Instrument allumination at 100% to make sure the bug is very visible.

Something has changed with perhaps the 'autostart', and even the 's' (starter). Previously I could adjust the altimeter to AGL zero before starting the engine... Now on the 's' key, it seems it reset the STD QNH? Turned out a new default feature called "Complex start up procedure" defaulted to Off, and the jsbsim listener on starter would do 'another' autostart for you when you pressed 's'. Ensure this option is checked if you want the previous default behaviour...

 Also strange the 'autostart' does not including setting the parking break prior to engine start, and run up for magneto check...


Version Views:

Over mp... meeting was at YGIL
aerial view of ygil from 1000 ft circuit

Pilots participating were

  • GA001 in XP PC, using Release 3.4
  • GA006 in Ubuntu, using built 3.5
  • GA007 in Win7-PC, using built 3.5

All were connected using mpserver01.flightgear.org

GA001 - View in 3.4 Release GA006 - View in 3.5 ubuntu-build GA007 - View in 3.5 win-7-bld
fleet v1 fleet_v2 fleet_v3

There are a few model issues.

The first in 3.4 release, and probably well back from that, the model is the current model, since that is all the model loader can find... but then it would not have access to any new textures anyway, so this is fine... 3 of the SAME... Looks good and neat... no problems...

In 3.5 to 3.5 viewing - some questions,
1. c172p: You seem to lose your livery. Is this sent over mp? ... I think so ... both aircraft are in the default livery, but it seems the ai model is loaded with the 'blue' coat...
2. General: The ai model can 'disappear' at specific angles, usually less than a deg or 2... moving the scene back and forth can show this on/off model view... only the pixel view... the pilots list, chats,... mp stays working, unchanged... Having 2 or 3 lined up like the above can help 'discover' it, zooming in and out, to get a better camera angle... Maybe this is an old bug, not related to the new c172p.

Updated: Was in 3.5+ to 3.4- viewing: It seems the 'broken' wing problem when 3.5+ views of 3.4 over mp, is fixed. But you could almost get to like such a SAD, but a little funny, perhaps rundown c172p ;=(( Due to a recent merge of fgdata and c172p-detailed means this fix is now what is in fgdata. ;=)) so may never ben seen again...

sad, like a cartoon character
Looks forlorn and lost... ugly duckling syndrome

Is this an inevitable compatibility problem? That is all our current user MUST upgrade to 3.6 which is YET to be released, else they appear as this laughable c172p cartoon aircraft view in all 3.5/3.6/++ views. Hardly a satisfactory view... but NO, thankfully this did not happen...

It is not really broken. It can still participate in accurate formation flying. The model doing the actual flying is NOT broken! Have read 3.6 expects something to arrive over mp which does not, and will never get from a 3.4- installation! Should init such a property to 'not broken' before the first mp packet arrives... it seems this is now done...

Face off high noon at KSFO, in front of the hangar
In 3.5, looking at a 3.4
Can not image what the gossip will be about back at the bar. Like who brought that ugly duckling to the party ;=))

20150706: Happy Ending : A YGIL quick re-visit

And there were many smiles.
Some nits, which may be in the old version as well (a) Lights shown as ON, and too glary, but off in remote mp, or maybe they remain in the 'broken' state (b) prop not spinning, even though the engine was on in remote,
but the important issue, NO broken wings ;=))
Fixed here it seems e3ad3555, authored by onox. Just missed it when doing the above fleet meeting images.



Really NOTHING to do with the new c172p. I was experimenting with a perl script I have had for quite some time. It computes a YGIL circuit to fly, but am getting something very wrong...

Circling at 1000 feet AGL, over YGIL While I did not expect a perfect rectangle with nice neat 90 degrees turns to the next heading, I also did not expect this straggly tracks... In the above update, have managed to smooth this out quite a lot, especially a 'computed' heading taking account of the wind speed and direction, which I think is the reason for this curved nature of these early attempts using just the computed true heading.

more like circus circuits!!!

One can see there is a repeated 'pattern' emerging, but there are some deviations, not yet undrstood...

Here I have 4 gps co-ordinates (wgs64) being the corner posts. The aircraft is on full autopilot, resting in the cabable hands of KAP140, so to fly the course I just need to move the heading bug appropriately. The autopilot will correctly bank left or right to turn to the new heading. A 90 deg turn takes 30 - 40 seconds to complete at the bank angle chosen.

There is an occasional meltdown if you set a course 180 degrees opposite. Some times the ap will try left, but before executing the turn right idea wakes up and turns right. This mean you can experience gently rocking of the aircraft while the ap makes up its mind and commits... Of course this can be avoid if the hb change is computed into two steps +/- 90 left or right to establish turn direction definitely, wait turn commences, 5, 10, ++ secs, then set the final close to 180 about face.

The main trick is to anticipate the turn, and commence the turn to the new heading say 15-20 second before reaching the next point. Somehow I am NOT getting this right... In fact it can do a dive of 5/10/+ just before the point, away from the known next pt, probably due to ????

Sort of plaged with why are these curves at all... this is small 5-10 Km max set of 4 points... simple from current postion, what is the heading to that target point, set hb... why later calcs also seemed messed up... also feel I may have confused setting mag vs true somewhere... As later noted, some of this was cleared up when began using the 'computed' heading that takes account of the wind speed and direction.



Just other thoughts...

How to present or improve the tutorial? I tried the first, but sometimes it was hard to get it to move to the next stage... must look at this...

More on adding back the magnetic compass tooltip. Came across Settings: from learntofly
The Heading Indicator must be set according to the Magnetic Compass indication before takeoff, and occasionally adjusted to the Magnetic compass while the aircraft is in steady, level flight. Precision error must be corrected for at regular intervals of about 15 minutes by re-calibrating the Heading Indicator (HI) to the Magnetic Compass.

Scenery comparison: Just the difference between 1.0.1, and later terrasync svn view around YGIL

fleet v1 fleet_v2

Definite color tonal changes. Rivers narrower, thus a little harder to see, but overall think it is an improvement... using terrasync mostly...

Participated in adding some tooltip to the autopilot. Tool chain of fork, develop, test, push, pr is quite exhausting, but it worked very efficiently...

Also participating in the release of HTML Tidy 5.0.0.RC1.  This is the next step in the eveolution of this great library and simple command line pretty HTML/XHTML printer, that does a lot more 'fixup!' if asked...



XG(raph): This is a simple format for displaying 2D points, lines, closed shapes. When the above YGIL circuit xg is loaded, this is what it looks like -
View of YGIL R/L circuits in Polyview2D
The forked source for this Polyviewer2D is part of my osm2xg project. It requires Qt4 to be installed. Win32 and 64 binaries, which include the Qt4 runtime DLLs.



EOP - fgc172p.htm

checked by tidy  Valid HTML 5