Jump to content
B21

Soar Dg808s Version 3 Available For Free Download

Recommended Posts

I was thinking I may have inadvertently hit the apply brakes key, thereby activating the TrimWizard.

Likely, that. If the TrimWizard is activated it operates the trim so that the aircraft's pitch is constant. Any action from the stick is compensated (if possible). So if you are not in the attitude you want, and try to correct with the stick while the wizard is active you fight each other until the stick rests at one of its boundaries. The suggested procedure is applying the desired attitude for the neutral stick position, pull the trigger and release the stick (gently) to neutral, release the trigger and fly along.

What I did after, was delete all the controller assignments for brakes.

And so you have no TrimWizard at all anymore, because it looks for the "Apply Brake" event which is on the joystick trigger for most. If it isn't mapped anymore to anything, no TrimWizard.

There might be an additional issue, as the the TrimWizard is designed for incremental operation. If you have mapped the trim to a joystick axis, the wizard will not work, because trim is reset to the axis position whenever the joystick sends an update.

best regards,

Peter

Share this post


Link to post
Share on other sites

... it looks for the "Apply Brake" event which is on the joystick trigger for most....

Hah! That's it I'm sure!

Without even testing, I know that I'm always clicking my joystick trigger inadvertently, and having trim on rotary just conrtibuted to the issue.

Since the rotary trim works perfectly for me, I think I will just disable the TrimWizard in the aircraft panel, and put my brake assignment back.

Thanks!

Share this post


Link to post
Share on other sites

Just some question/clarification on the Cambridge instrument and GPS:

If there is some more detailed documentation or forum post, just point me to it.

As far as I could tell, the arrival height it displays seemed to be the finish, rather than next TP. Is that the way it works?

Although I can change the MC setting, and see corresponding change in arrival height, I could not see anthing that was commanding Speed-to-fly. Should I see that anywhere with this particulare instrument? Unable to find such an indicator, I resorted to watching for changes in arrival height, and speeding up or slowing down accordingly.

Also, in my recent multiplayer flight, my friend did not see the waypoint data from the save flight I was hosting on his GPS. Only thing showing on his LCD was "NO ACTIVE WP". How is it supposed to work?

[EDIT] Hold on....I still have the two b21_vario_ folders in my ...Airplanes\DG-808S_SOAR\panel.virtualsoaring\ folder! I guess those should have been put into the GAUGES folder, right! Doh!!!

Share this post


Link to post
Share on other sites

The ASW28 panel intro is given in this thread at UKVGA. I should stick it on a web page I suppose... you may need to register with their forum to see it...

arrival height it displays seemed to be the finish, rather than next TP. Is that the way it works?

The Cambridge is showing arrival height **AGL** at the next waypoint. The only instrument that calculates arrival height all the way around the task is the SDI C4 in the Aerosoft Discus (I should know, I wrote the code for both...)

I could not see anthing that was commanding Speed-to-fly.

There's no Speed-to-Fly indication in any glider except the Aerosoft Discus, although the needle in the Cambridge is showing NETTO (and the Winter vario shows TE) so you should know when to speed up and get the hell out of there...

Also, in my recent multiplayer flight, my friend did not see the waypoint data from the save flight I was hosting on his GPS. Only thing showing on his LCD was "NO ACTIVE WP". How is it supposed to work?

Did he have the .PLN file and the .FLT the same as yours? The .PLN file is the thing that guides the GPS. Both files are plain text and can be viewed in an editor. To give the .flt PLUS .pln files to someone else, you have to remove a reference to YOUR "Documents" folder in the .FLT file... If you look in the .FLT file with Notepad, you'll see a reference to the .PLN file as something like "C:\Users\Freddie\Flight Simulator X Files\funky_task.pln" which works if your name is Freddie but not for anyone else... (MS cocked up). The fix is to change the reference simply to "funky_task.pln", i.e. remove the folder name part, and it will still work for you and also for anyone else.

Another hint... IF you ever hand-edit the .PLN file, be careful of the "degree symbols" in the Lat/Longs. These are Unicode characters and you have to be careful when you save the file in a text editor that you don't save as ASCII and cause them to disappear.

B21

Share this post


Link to post
Share on other sites

There's no Speed-to-Fly indication in any glider except the Aerosoft Discus

I've just downloaded your b21_vario_netto, and the screenshot, and bitmaps for it, seem to be showing a "push-pull" indication, which is what I mean by speed-to-fly.

http://carrier.csi.c...fsx/simobjects/

But I just tried out that gauge, and it seems the push-pull arrows are just static bitmaps on the face, not actually functioning.

Did he have the .PLN file and the .FLT the same as yours?

Hmmm, no he didn't. In my ignorance of FSX multiplayer, I had assumed that the hosting process would transmit the flight plan I selected to him.

So that's not what happens, then?

Share this post


Link to post
Share on other sites

The Cambridge is showing arrival height **AGL** at the next waypoint. The only instrument that calculates arrival height all the way around the task is the SDI C4 in the Aerosoft Discus (I should know, I wrote the code for both...)

I'll fly with it some more and see. On the short 112km task we flew yesterday, the only time the indicated arrival height made any sense to me was on final glide. At the start, it was showing -2300 meters, and approaching first TP, when close enough to see I would arrive with plenty of height, it was still showing -500 meters, and that was with MC still set at 0.0

Only on last leg, after climbing in last thermal, did the number rise into the + range. By then I had bumped the MC up to 2.0

Share this post


Link to post
Share on other sites

I'll fly with it some more and see. On the short 112km task we flew yesterday, the only time the indicated arrival height made any sense to me was on final glide. At the start, it was showing -2300 meters, and approaching first TP, when close enough to see I would arrive with plenty of height, it was still showing -500 meters, and that was with MC still set at 0.0

Only on last leg, after climbing in last thermal, did the number rise into the + range. By then I had bumped the MC up to 2.0

The push-pull indicators were a carry-over of the gauge background from the original stock vario in the Microsoft gauge - they didn't do anything there either. In stock FSX, the variometer is simply a rate-of-climb indicator, i.e. not even compensated, but it had some nice graphics.

FSX Multiplayer synchronises time and weather but nothing else AFAIK (assuming you're using FSX IP multiplayer) so each pilot loads their own task - makes sense if you assume a mix of power pilots which is far and away the main FSX constituency. For soaring of course you can agree a task beforehand and distribute the .PLN. There is *very* little experience of multiplayer soaring in FSX - the Microsoft model was to use Gamespy, and some random users desktop PC (typically a 10-year-old) would appear as a server, you'd connect to it, and when the 10-year-old quit his flight 2 minutes later that would be the server gone. The whole multiplayer approach was deeply broken with no dedicated servers.

Re arrival height, the indication is ***AGL*** at the next turnpoint, in either meters or feet depending on your FSX setting. Perhaps your TP1 was higher than the start airfield? That doesn't explain your 'approaching first TP' comment - any chance the GPS had already swtiched to the second TP (that happens in FSX when you cross the inbound/outbound bisector - this often happens early if the inbound/outbound angle is very acute and is actually the trigger used by Garmin).

I've collected my ASW28 info here from info I produced for inexperienced pilots at UKVGA - it might not have any detail you need.

B21

Share this post


Link to post
Share on other sites

FSX Multiplayer synchronises time and weather but nothing else AFAIK (assuming you're using FSX IP multiplayer) so each pilot loads their own task

OK, that seems to explain it. We used GameSpy interface, I hosted, and chose the Flight Plan, then waitied for my friend to join. I don't know what it looked like from his end.

Re arrival height, the indication is ***AGL*** at the next turnpoint, in either meters or feet depending on your FSX setting. Perhaps your TP1 was higher than the start airfield? That doesn't explain your 'approaching first TP' comment - any chance the GPS had already swtiched to the second TP?

It hadn't switched, I had read about that, so was watching it closely. I wonder if it is the closed, triangular tasks I have made, where takeoff and finish are the same location, which are tripping up the GPS? I notice when I load the resulting IGC into SeeYou, it shows two comments:

"Task Declaration is NOT VALID!"

and

"All reached turnpoints rounded OK, task not finished."

I'll give it a try with a task that has different start and finish locations. Plus, I have a number of questions about constructing soaring tasks using either the FSX Flight Planner, or Plan-G, and if I can't answer them by messing around myself, I'll make a post here.

Share this post


Link to post
Share on other sites

different start and finish locations

the LCD vario is only querying FSX to get the bearing and distance to the next waypoint. If there's a mission loaded then the LCD vario will use the next Point-of-Interest (a mission object) to override the waypoint in the flightplan. The GPS-NAV at the top of the panel is taking the exact same info from FSX (bearing and distance to next waypoint) and displays the waypoint name so you can confirm what FSX thinks it's doing. It is *FSX* that decides how far around the flightplan you've gone, and switches forwards to the next WP, not the gauges, and FSX just gives info to the next WP. The start and finish locations being the same is completely transparent to the gauge (it's only ever seeing one waypoint ahead) - FSX doesn't mind either except for the in-built flight plan editor... (there is no convenient API to ask FSX for the complete task from within a panel gauge, although I came up with a cunning method for the Aerosoft Discus)

The LCD vario arrival height computation hasn't had a problem as far as I know, and plenty of people have used the glider, so I suspect a dodgy flightplan. If you post up your .PLN and .IGC files up here it will be a lot easier to say where things have gone adrift.

B21

Ah... I've just had a guess of where you might have a problem - I've misled you with 'AGL' as the definitive arrival height... this *assumes* you set the height of the waypoint in the flightplan to be ground elevation at that point, which is the default behaviour of FSX. I.e. the LCD vario is showing your arrival height relative to the height given in the flightplan appropriate for that waypoint. If you have manually set this to some figure, e.g. 4000 feet, then the arrival height will be relative to that value. I'll put money on this is the discrepancy. Apologies for this - my documentation may be a bit sparse. The upside is you can purposely set a WP height in the task (say on the last WP) that puts you on final glide for the finish.

Share this post


Link to post
Share on other sites

OK, I did not change anything in that box, but every waypoint I add is using a default "Cruising altitude" of 1368 meters. I don't know where this comes from, but FSX is showing it in a box below the flight plan map. I *can* change it, but just left it. So if I Edit the waypoint, that number show up in the Altitude box. I don't see anything for finding the ground elevation at the waypoints. If I open the .PLN, I can see the elevations there as part of the <WorldPosition> tag. All the numbers there look right, albeit they are in feet, i.e. Belleville (CNU4) is 320' ASL:

<?xml version="1.0" encoding="UTF-8"?>


<SimBase.Document Type="AceXML" version="1,0">

    <Descr>AceXML Document</Descr>

    <FlightPlan.FlightPlan>

        <Title>CNU4 to CNU4</Title>

        <FPType>VFR</FPType>

        <CruisingAlt>4491</CruisingAlt>

        <DepartureID>CNU4</DepartureID>

        <DepartureLLA>N44° 11' 37.87",W77° 18' 13.78",+000320.00</DepartureLLA>

        <DestinationID>CNU4</DestinationID>

        <DestinationLLA>N44° 11' 37.87",W77° 18' 13.78",+000320.00</DestinationLLA>

        <Descr>CNU4, CNU4</Descr>

        <DeparturePosition>26</DeparturePosition>

        <DepartureName>Belleville</DepartureName>

        <DestinationName>Trenton</DestinationName>

        <AppVersion>

            <AppVersionMajor>10</AppVersionMajor>

            <AppVersionBuild>61637</AppVersionBuild>

        </AppVersion>

        <ATCWaypoint id="CNU4">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 11' 37.87",W77° 18' 13.78",+000320.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CNU4</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

        <ATCWaypoint id="CPF8">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 24' 12.00",W77° 45' 34.00",+000630.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CPF8</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

        <ATCWaypoint id="CANAL">

            <ATCWaypointType>Intersection</ATCWaypointType>

            <WorldPosition>N44° 3' 38.23",W77° 37' 48.94",+000000.00</WorldPosition>

            <ICAO>

                <ICAORegion>CY</ICAORegion>

                <ICAOIdent>CANAL</ICAOIdent>

                <ICAOAirport>CYTR</ICAOAirport>

            </ICAO>

        </ATCWaypoint>

        <ATCWaypoint id="CNU4">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 11' 37.87",W77° 18' 13.78",+000320.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CNU4</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

    </FlightPlan.FlightPlan>

</SimBase.Document>

However, in the .FLT, under [GPS_Engine] I find this:
WpInfo0=41, 0, 97, 0, 0, 0.0, 0.0, 0.0

WpInfo1=62, 0, 1368, 0, 0, 0.0, 0.0, 0.0

WpInfo2=63, 0, 1368, 0, 0, 0.0, 0.0, 0.0

WpInfo3=63, 0, 97, 0, 0, 0.0, 0.0, 0.0

There is correct field elevation for WP 0 and 3 (Belleville, 97m) but the other two are using the 1368m "Cruising Altitute" I mentioned above. If that is what the GPS is using for arrival height calculations, the you are correct about why it is not what I expect to see, until I round the last WP and start final glide. "Dodgy flight plan" was the technical term you used.

As far as not starting the task in the IGC, I have an idea why that happens, but don't know how to fix it. The .FPL above also has an entry:

NextWP=1

As soon as I spawn in at CNU4 (on the runway) the GPS is pointing to CPF8, so we did not make a proper start. I have many more questions about tailoring these flight plans to soaring tasks, but I'll open another thread for that later.

Thanks for taking the time to troubleshoot this.

Share this post


Link to post
Share on other sites

good diagnosis.

Your 'Intersection' 'waypoint type' is bad for soaring in your intermediate waypoints (Intersection - takes 'cruising altitude' as the waypoint height). There is some better type to choose - take a peek at Task 2 .PLN or maybe the .PLN in one of my MIfflin missions - I can't remember offhand the better type (and I'm on a Mac right now). From memory also FSX flightplans *must* start and end with an airport so watch out (your example does so its ok).

Also you see FSX files sometimes use FEET, and sometimes METERS as alt values...

If you're *at* an airfield, and that's the first waypoint, then FSX assumes you've reached that waypoint and the *next* WP will appear to be the 'next WP' as far as FSX is concerned when the flight starts. There are a variety of hacks to get around this - often we start the soaring flight in the *air* approaching the start airfield, so the start point shows in the GPS. You can try other hacks such as duplicating the startpoint as the first waypoint in the PLN file (using a text editor but you have to reload the FLT and save it so the gps section gets updated) - you're trying to fool FSX at this point - it doesn't crash with duplicated WPs i.e. a zero length leg... also you can try hand-modifying the 'next wp' index in the FLT file, but you're at risk of having FSX triggering you reaching the WP immediately on start. Alternatively have a start point that is near the airport but is not actually the airport - this is common in R/L soaring - i.e. you have something like "Lasham Start Point A" not far from the airport at Lasham.

FYI there's a lot of information on file formats in the online msoft docs: http://msdn.microsoft.com/en-us/library/cc526948.aspx (or install the SDK). It's a complete rabbit hole though and you can spend hours in there trying to resolve an issue.

B21

Share this post


Link to post
Share on other sites

Hand editing the NextWP=0 seems to work for the start issue. Not sure how that will affect the IGC yet. Your other suggestions for start arrangements are also worth trying. We do airstarts in Condor often, but I always like going through the takeoff and tow. It just makes it seem more "real".

Also, hand editing the WpInfo elevations under [GPS_Engine] makes the arrival height display correctly.

Yes, CANAL was an unfortunate choice. I thought it was the Murray Canal, which would be a good visual landmark. Although it is located at the canal, it is as you said, actually an airway intersection. I have Plan-G installed now, so will try making some tasks with that and see how it goes.

Share this post


Link to post
Share on other sites

hand editing the WpInfo elevations under [GPS_Engine]

Good test to confirm, but less 'dodgy' would be to edit the .PLN to get the elevations correct, reload the flightplan and save the .FLT again. This will ensure the FLT is in sync with the PLN.

If you post up the IGC I'll guess why you'd get 'task not completed'. The 'task declaration not valid' is odd but I'd need to see what SeeYou wants.

B21

Share this post


Link to post
Share on other sites

The elevations in the .PLN *are* correct. It is only the [GPS_Engine] section of the .FLT that are using the cruising altitude.

I'm pretty certain the problem with the IGC is that we did not pass through the start sector before heading out to first WP. Best thing would be to edit this task, change the CANAL waypoint to something more appropriate, and fly it again.

BUL_DG-808S Belleville Task 112km_2010-12-21_2100.zip

Share this post


Link to post
Share on other sites

The elevations in the .PLN *are* correct. It is only the [GPS_Engine] section of the .FLT that are using the cruising altitude.

I agree there's a major discrepancy between the [GPS_Engine] section of the FLT and the ATCwaypoint entries in the PLN - I've never seen that before, maybe the intermediate 'Intersection' waypoint type in the PLN with an altitude of +0000000 is the cause I know it sounds improbably but something screwed it up... E.g. you could fix the PLN with


        <ATCWaypoint id="CNU4">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 11' 37.87",W77° 18' 13.78",+000320.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CNU4</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

        <ATCWaypoint id="CPF8">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 24' 12.00",W77° 45' 34.00",+000630.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CPF8</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

        <ATCWaypoint id="CANAL">

            <ATCWaypointType>User</ATCWaypointType>

            <WorldPosition>N44° 3' 38.23",W77° 37' 48.94",+000000.00</WorldPosition>

            <Descr>CANAL</Descr>

        </ATCWaypoint>

        <ATCWaypoint id="CNU4">

            <ATCWaypointType>Airport</ATCWaypointType>

            <WorldPosition>N44° 11' 37.87",W77° 18' 13.78",+000320.00</WorldPosition>

            <ICAO>

                <ICAOIdent>CNU4</ICAOIdent>

            </ICAO>

        </ATCWaypoint>

I'm not sure whether you say SeeYou isn't picking up the task from the IGC file (it looks ok to me) or is just not recording a start. If it's just the latter then perhaps you can change the start type (in SeeYou) from a line to a cylinder, and then it'll pick up a good start. Maybe... Your IGC file looks fine:

AXXX sim_logger v2.31

HFDTE060810

HFFXA035

HFPLTPILOTINCHARGE: David Bulau

HFCM2CREW2: not recorded

HFGTYGLIDERTYPE:SOAR DG808S

HFGIDGLIDERID:BUL

HFDTM100GPSDATUM: WGS-1984

HFRFWFIRMWAREVERSION: 2.31

HFRHWHARDWAREVERSION: 2009

HFFTYFRTYPE: sim_logger by Ian Forster-Lewis

HFGPSGPS:Microsoft Flight Simulator

HFPRSPRESSALTSENSOR: Microsoft Flight Simulator

HFCIDCOMPETITIONID:BUL

HFCCLCOMPETITIONCLASS: DG

I023638FXA3941ENL

C211210210040000000000102CNU4 to CNU4

C4411631N07718230WBelleville

C4411631N07718230WCNU4

C4424200N07745567WCPF8

C4403637N07737816WCANAL

C4411631N07718230WCNU4

C4411631N07718230WTrenton

L FSX user PC time        	2010-12-21_2100

L FSX FLT checksum        	G6M6OI (flight simulator x files\DG-808S Belleville Task 110km.FLT)

L FSX WX checksum         	5OL85M (flight simulator x files\DG-808S Belleville Task 110km.WX)

L FSX CMX checksum        	000000 (not found)

L FSX CumulusX.exe checksum   DJCIJC

L FSX mission checksum    	000000 (not found)

L FSX aircraft.cfg checksum   2B090C (DG808S_SOAR\aircraft.cfg)

L FSX AIR checksum        	7QDJ3T (DG808S_SOAR\virtualsoaring.AIR)

L FSX CumulusX status:    	UNLOCKED

L FSX WX status:          	LOCKED OK

L FSX ThermalDescriptions.xml REMOVED OK

L FSX GENERAL CHECKSUM        	O1477D  <---- CHECK THIS FIRST

B1748424411628N07718240WA0009700097027000

B1748464411628N07718240WA0009700097027000

B1748504411628N07718240WA0009700097027000

...

The 'C' records are the task.

B21

Share this post


Link to post
Share on other sites

I'm not sure whether you say SeeYou isn't picking up the task from the IGC file (it looks ok to me) or is just not recording a start. If it's just the latter then perhaps you can change the start type (in SeeYou) from a line to a cylinder, and then it'll pick up a good start. Maybe...

Yes, it is the latter. We didn't pass through the default start waypoint, which is like a little 500m circle, and we didn't do that because the GPS was navigating us to the next waypoint. Yes, I can get SeeYou to show the task as started and finished by changing flight properties so the the start line is longer.

I just made another test task, this time created the flight plan in Plan-G, a very short triangle, and saved it to FSX .PLN file. Then opened that in Flight Planner, set weather, aircraft, time, etc. and saved as a FreeFlight. Hand edited the .FLT as discussed previously, i.e. GPS elevations, NextWP=0. Flew it, and absolutely everything worked as expected. During takeoff and tow, GPS pointed to CNU4 (the spawn airport, and the start waypoint). After release, thermalled a bit, then blew across the runway on a heading for the first leg. Crossing the runway, GPS switched to first waypoint, etc. etc. Arrival heights all as they should be, and crossing the runway back at CNU4 for the finish, the GPS switched to "No Active AP".

Saved IGC looks correct in SeeYou. I shows the entire task flown and completed, but still says Declaration is NOT VALID! In RL soaring with PDA, is there not a requirement to "Declare" the task before starting? I don't know how to do that in SeeYou.

In any case, I'm beginning to understand that SeeYou can be tailored to match the way the task was intended to be constructed, start sector or line, lenght, turnpoint sector or cylinder, radius, etc. Whereas the cockpit GPS is very primitive, and assumes each waypoint is a small cylinder.

BUL_TestTask1_2010-12-24_1714.zip

Share this post


Link to post
Share on other sites

well done - once you've worked out the quirks with FSX life gets a lot easier from here on...

The FSX inbuilt 'gps engine' uses the then current Garmin algorithm to switch from one waypoint to the next... when your aircraft crosses the bisector of the inbound and oubound track at a given waypoint. You're right, it's basic, and particularly doesn't work well if you have a WP at a very acute corner of the task (if you drift over the bisector on your way towards the waypoint, the GPS switches. I.e. on the image below, if you're travelling A-B-C, and next WP is B, GPS wil switch when you cross the red line.

wykobi_bisector.png

The GPS switching has absolutely NO impact on what's being logged in the IGC file - this has the task declaration at the top (C records) followed by a long stream of timestamp/lat/long/alt records (B records).

A panel/gauge designer could re-write the GPS engine from scratch, i.e. just get the current lat/long/alt from FSX and implement it's own task management and algorithm for changing waypoints, and sim_logger does something a bit like this, but that is a hell of a lot of work.

I don't know what SeeYou is expecting to accept the task declaration as 'VALID' - if you have some documentation let me know. The IGC standard says put those 'C' records in the IGC file, which are there, and various other software picks up the task out of the IGC file ok. I assume this is all to do with SeeYou authentication of the task declaration - maybe SeeYou expects you to decare the task in SeeYou and upload it to the logger, or SeeYou tries to check the authentication key (G record) at the end of the IGC file, and only has the authentication key formula for certain loggers (sim_logger does embed a security checksum in the IGC file, but only sim_logger can check its own authentication key)

Well done again - in a short time you've really got this sorted.

Happy xmas,

B21

Share this post


Link to post
Share on other sites

Is there an LNAV_polar.dat available for this airplane? I'm going to try using the CAISet gauges, and just need a polar for the LNAV gauge.

If not, I've dug around online and found some resources, and maybe can figure out how to make the file.

Ian, is your L/D gauge available for download?

Share this post


Link to post
Share on other sites

Sorry slow response but I didn't notice the last line of your post...

Ian, is your L/D gauge available for download?

The Cambridge 302 LCD vario in both the SOAR DG808S and the UKVGA ASW28 have a hidden embedded 'L/D' readout in the form of a gauge element with the visibility set to zero by default, which you can enable via a text edit.

To enable the L/D reading on the 302 display, you will need to edit the xml file of the gauge using Notepad or similar (I recommend Notepad++, not that you need it, but it's a good replacement for Notepad).

The file is called:

SimObjects\Airplanes\DG808S_SOAR\panel.virtualsoaring\b21_vario_v2\variometer.xml

Right-click the variometer.xml file, Open with.. Notepad, and about half way down you'll find the section:


    	<Comment><Value>*******************************************************

                	L/D Ratio

 		**********************************************************************

 		</Value></Comment>

    	<Element id="L/D ratio">

        	<FloatPosition>4.000,35.000</FloatPosition>

   		<Visibility>0</Visibility>

        	<GaugeText id="actual glide ratio">

            	<Size>30,20</Size>

            	<FontFace>Quartz</FontFace>

            	<FontColor>#505050</FontColor>

            	<FontHeight>20</FontHeight>

            	<Length>2</Length>

            	<Transparent>True</Transparent>

            	<HorizontalAlign>RIGHT</HorizontalAlign>

            	<VerticalAlign>CENTER</VerticalAlign>

            	<GaugeString>%( (L:B21_vario_v2_actual_glide, number) )%!2.0f!</GaugeString>

        	</GaugeText>

    	</Element>

You have to change the '0' in the <Visibility> tag to a '1'and the L/D reading will appear on the 302 in the 9-o'clock position in the space that is currently empty:

302.png

I've used the L/D gauge so much in my FSX development, in the LS8-18 (of Wolfgang Piper) that I'm working on I've got off my ass and added code to toggle the L/D display by clicking on that area with the mouse.

B21

Share this post


Link to post
Share on other sites

The Cambridge 302 LCD vario in both the SOAR DG808S and the UKVGA ASW28 have a hidden embedded 'L/D' readout in the form of a gauge element with the visibility set to zero by default, which you can enable via a text edit.


                <FontFace>Quartz</FontFace>

Thanks, Ian! Got it.

Does the above line mean we can sub any font?

Or are we truly stuck with the MS Quartz?

Share this post


Link to post
Share on other sites

Does the above line mean we can sub any font?

You can change it, e.g. <FontFace>ARIAL</FontFace>. Less authentic, but easier to read. I've taken a compromise approach in updating the GPSNAV - the numbers remain 'quartz' but I've made them as big as I can, while the waypoint name is some other font (I forget which). Numbers are just about ok, but Quartz is particularly bad for alphabetic.

gpsnav.png

B21

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...