The work on implementing support for a Navigraph navdata database is progressing well.  Many of the basics are already in place at this point.

• Replaced the default Flight Simulator lateral navigation autopilot with custom code.
• Lookup and data for all intersections now come from the external database.
• Selection of a departure runway, a SID as well as any possible transition is in place.
• Selection of a destination runway, a STAR/transition and an IAP (arrival)/transition is in place.

The next step is the creation of all the custom waypoints that are defined by SIDs, STARs and IAPs.  Many of these terminal procedures have specific behavior requirements that the default Flight Simulator autopilot simply can not handle.  So after we load the waypoints correctly, we’ll next have to write yet more custom autopilot code to support the terminal procedures.

After we get the new autopilot code working, the last step of all of this is to implement a bunch of new flight plan drawing on the MFD.

Below is a screen shot in the VC.  If you look closely on the left-hand FMS console… you might notice that the arrival selections have been made by the pilot.  Simply click on the image to see the full size version.

It’s been a while since I’ve posted anything here.  The majority of my time is filled with work on the Citation X 2.0’s Navdata Service Upgrade that we’ve promised.  Because of this upgrade, we’ve had to do a bit of extra work to make it happen.

The Primus 2000’s flight guidance computer can handle some rather complex SID/STAR methods, which means the default Flight Simulator’s autopilot just doesn’t cut it.  We’ve replaced all of the Flight Simulator autopilot for vertical flight control with the exception of the basic altitude hold.  Our VNAV and FLC use custom code to control the aircraft’s behavior in the vertical path.  In VNAV mode it can fly a predefined climb/cruise/descent vertical path based on airspeed, altitude.  It supports waypoint altitude restrictions in both climb and descent and can fly an extremely accurate path either up or down.

Now we’re having to take the time to write a custom lateral navigation autopilot so we can support such things as a DME arc or an RNAV approach that uses a set of waypoints to define a circle to fly around.  These are but a couple of lateral control processes that Flight Simulator’s default autopilot can’t even spell, let alone fly.

Everyone’s chomping at the bit for the release, and I can certainly understand why.  However, we intend to take our time on this and work hard to get it as close to 100% as we can.

Well, tis the season!

Our Citation X 2.0 is released, just in time for the holidays.  We debated holding up release until after we had completed the nav data integration, but we decided to release so that people could start enjoying the aircraft now.  I'd like to thank everyone for being patient and understanding as I work hard at getting all the Navigraph nav data support in place.  In the mean time, the aircraft is still useable.

We had a few issues with the flight dynamics, but that's been taken care of.  As with any software product, there are issues.  Seems there's always issues. However, our commitment to the product is unchanged and we'll resolve any and all issues if it's possible.

Thank you for your patience and I hope you enjoy your new aircraft.

In case you missed the announcement in the Eaglesoft forums, the Citation X 2.0 has gone to beta!  Yes, that's right... it's release is getting closer.

It's been a long, hard road getting to this point and I hope that our customers appreciate the results.  For more information and details, head on over to the  Eaglesoft Forums.

If you didn't see the entry in Bobby Haye's blog regarding the Citation, you might want to wander on over.  We've added a feature that's not quite available yet on the real deal, but has been in flight testing for a while now.

We're still working hard on this puppy, with the visual 3D modeling almost complete.  Liveries are being designed, appearances cleaned up and finalized.

In the panel department, pretty much all the gauges are in place and functioning, complete with complex system behavior designed and programmed behind the scenes.  The flight management system is the primary focus at this point.  So, I'm spending hours on end working on implementing the user interface to support creating flight plans using the system's twin CDU's.

Here's a shot of the X, in flight flying a flight plan created inside the FMS itself.  The route is from KCMH to KFMY using "HNN,SPA,GRD,IRQ,J53,DUNKN" as the waypoints between.

Ok, not the best of titles... but, it's on topic.

With all the glass in this cockpit, there's definitely a need for backup instrumentation.  The Citation X definitely has it and here's what they look like.  Sure, it's not much... but it's progress. ;)

So, there they are... the 3 primary standby instruments.

Work is progressing, but at this point most of the things being completed are not things that are visible.  It's difficult to show progress in lines of code.

Work on the Citation X 2.0 is continuing.  Most of the VC gauge placement and lighting is in place.  A couple more systems to complete and then it's all flight management.

Here's a couple screen shots... I'm telling ya, it's like night and day! ;)

Well, just thought I'd put up a short post about the Citation X V2.

Work is still progressing on the project.  Bobby and Bill are working on putting the finishing touches on the virtual cockpit's night lighting behavior.  Myself, I'm busy working on finishing off gauges for the center console.

Once all the gauge functionality is in place, the next step will be finishing off the flight management system (FMS) code.

Our FMS is designed to support the default database built into FS, so users don't have to purchase commercial databases from other companies.  While working on the FMS, I stumbled across a web site with something interesting.

Apparently someone has taken the time to create a more up-to-date database for FS that is incorporated as part of the scenery.  This means the update would work with anything in FS that uses the default database.  I found it here:

http://uk.geocities.com/fs9.airac@btinternet.com/

Anyway... things are still moving along nicely.

Greetings everyone, it's been a few months since I posted anything and I thought I should probably take a moment and toss out a new post with updates regarding the upcoming Citation X 2.0 project.  This post I'm going to discuss aircraft electrical systems and how MSFS handles them.

To emulate an electrical system, MSFS provides several aspects you find on most aircraft in the real world.  Batteries, generators, alternators, electrical buses.  In the aircraft.cfg file for an aircraft in MSFS there's a section titled [electrical].  This is the section commonly used to set up the aircraft's electrical systems.  For a small GA-type aircraft, it generally suffices.  Unfortunately for any aircraft with a more complex electrical system it doesn't really do much.

You have the ability to map generators to engines, set the maximum amps a generator can produce, and the maximum voltage as well.  There are eight (8) predefined electrical buses that are supported by the aircraft.cfg file:

1. Main Bus
2. Avionics Bus
3. Battery Bus
4. Hot Battery Bus
5. Generator/Alternator Bus 1
6. Generator/Alternator Bus 2
7. Generator/Alternator Bus 3
8. Generator/Alternator Bus 4

The Cessna Citation X (750) was originally shipped with a single bus system but was later released with a dual bus system.  In our V1.0 Citation X project we released a panel based on the single bus system.  Our new V2.0 project will be based on the dual bus system.  The 750 has two primary batteries, a standby battery and an emergency lighting battery.  That's three (3) more batteries than MSFS actually supports.  I'll also mention that default battery life in MSFS is really bad.  There's no method or process that allows us to tell MSFS the actual capacity of the battery (usually measured in amp-hours).  Typically, the battery dies rather quickly in MSFS resulting in many the user asking why they lose gauges, can't start engines... etc.

In the dual bus system, the 750 has the following buses defined:

1. Left Battery Bus
2. Left Emergency Bus
3. Left Main Bus
4. Left Extension Bus
5. Right Battery Bus
6. Right Emergency Bus
7. Right Main Bus
8. Right Extension Bus
9. EICAS Bus
10. Standby Bus

As you can see, that's a few more buses than MSFS even admits can exist.  There are two battery buses, MSFS only allows for one.  There are emergency buses, main buses, extension buses... the list goes on.  MSFS simply won't allow us to use the built-in default electrical system to emulate the 750's electrical systems.  So, it's clear from the above that in order to provide any remotely accurate electrical system behavior, we would have to bypass MSFS's built-in electrical systems entirely. 

The Beginning

The first step was to deal with the battery support.  To do this, we've written our own code to emulate the Nickel-Cadmium (NiCad) batteries.  This means that the batteries will hold a charge based on their capacity and load over time, just like real ones do.  It results in a more accurate battery duration, which I think we can all agree is a good thing.

Next was modelling the physical buses and switches that interconnect it all.  Doesn't sound too hard, right?  Heh.  Writing software to mimic the actual behavior of electrical flow through wires and switches is far more complex than one might think.  A switch doesn't care which side has voltage and which side has a load.  It just allows electricity to flow through it if it's closed.  However, if the left bus switch is in the NORM position, all items on that bus get their power from the left main bus if it's got power... otherwise it places a load on the left battery.  Deciding how to define that programmatically was something new for me in my career.  I've never had to create voltage in a program before.  I also had to take into account the physical amperage load of individual systems and items that are turned on or off in the aircraft and what bus they place a load on.

Anyway, the final result is something I hope will be met enthusiastically.  Our 750's electrical system is about as close to the real deal as we can get it, right down to the actual amperage load on the system based on what's turned on and what isn't.

Wow, is January almost over already?  It seems the older I get, the faster the days go by.

Work on the Citation X 2.0 gauges continues.  The biggest change for V2 is, of course, the inclusion of a flight management system (FMS).  For a while the only type of flight management available in Flight Simulator was the default flight planner.  At the time of it's introduction it was a giant leap forward for flight planning.  With the inclusion of a GPS display interface it offered new capabilities for the GA crowd.  Unfortunately it offered only minimal enhancements for those who preferred to fly the heavy iron.  As time went by, some commercial developers released aircraft with their own FMS's in place.  This offered the heavy iron fans functionality that the default GPS interface simply couldn't offer.  Possibly the most significant FMS release was the Level D 767 that included a comprehensive simulation of the FMS systems available on that aircraft.

With our V2 release we intend to offer an FMS as well as updated GDI+ displays for the Primus 2000 displays.  To implement an FMS required a lot of thought.  We had to analyze what was already in place within Flight Simulator, what parts of that we could use and also decided what parts of an FMS we needed that weren't in FS.  The first thing that stood out is the completely inaccurate autopilot behavior that is a default in FS.  Most autopilot systems that are linked to an FMS offer a few autopilot vertical control modes that FS simply doesn't support.  Vertical navigation support of such capabilities like 'flight level change' (FLC) and 'vertical navigation' (VNAV)  literally doesn't exist within FS at all.  This means we have to write custom autopilot code to implement the vertical navigation modes most FMS's support.

There are also differences in how the altitude hold and heading hold modes work in many jets with an FMS versus what the default FS autopilot provides.  While these differences are far easier to deal with than the vertical navigation modes, they still require a bit of rework within the aircraft's gauge code to ensure they more closely match what the real world counterpart actually does.

There is also the issue of navigation data.  Because FS is a commercial product that is produced within a limited timeframe, and because Microsoft pays licensing fees for the navigation data FS contains... there are finite limits of time and resources that impact the accuracy of the navigation data shipped as part of FS.  The primary issue, accuracy, is impacted by having to impose a data 'lock-down' date when developing the FS product.  This results in the actual navigation data being out of date before the commercial product hits the shelves.  Most commercial add-ons that have their own FMS also have their own navigation database.  This is done in an attempt to ensure the user has the most current and up-to-date navigation data available to them.  This database update was a free service at one time, but due to various reasons is now a commercial product.  Most of these databases are full and complete replacements thus allowing the FMS software to completely ignore any navigation data contained within FS itself.  While this may sound like an ideal choice, it does indeed have a cost/impact.

As example, let's take KCVG.  A year or two back, they added a third runway to the airport.  Of course, in the real world all navigation data was updated accordingly and thus the real world FMS's were current.  However, in FS there were two steps required to bring a user's FMS current.  First they had to purchase the current navigation data from the commercial vendor for their add-on.  Then they had to locate an updated AFCAD file for the KCVG airport that added the third runway and adjusted the other two runway identifiers as well as added ILS functionality and other airport specific items.  If they failed to do that, their FMS could indeed support landing on the new runway.... and the ATC (if flying on VATSIM/IVAO) could indeed direct them to the new runway... but as they approached... there would be no runway!

To avoid this potential issue, we decided to take a slightly different approach.  First, absolutely no additional database is required whatsoever to use the V2's FMS.  You can install the aircraft and fly with what FS has to offer.  For those that want updated navigation data, we provide the ability to add supplemental data that updates and overrides the default FS data.  The only updated data supported is the navigational aids like NDBs, VORs, DME as well as SIDs, STARs and approaches.  Any data connected directly to an airport, such as runways and their affiliated ILS systems are obtained strictly from FS itself.  This prevents the issue of landing at a runway that doesn't exist from happening.  Now, it's probably safe to say this may not ever actually happen... but we really wanted to offer flexibility and reliability at the same time.

I could probably yak about this for a while longer, but I see your eyes have already glazed over.  Anyway... our FMS is coming along nicely.  Here's a couple of screen shots:

Our announcement regarding the update for the Citation X has been out for a while, and it seems time is just flying along.  People are wondering, I'm sure, why it's taking as long as it is.  The reason is simple in statement, complex in detail.  It's an extremely complex set of avionics and to do it justice means it takes longer than your typical GA aircraft.

When tasked to create the next version of the gauges for the Citation X, I had two goals I wanted to accomplish:

1. Implement an accurate Primus 2000 avionics suite.
2. Find ways to accomplish features that the default FS doesn't support yet do do without stepping outside the 'sandbox'.

One of the 'risks' involved in interacting with the public regarding an ongoing project is that there are always those individuals who take a preliminary info release as 'set in stone'.  Thus ensues the arguments regarding 'promises' or other such nonsense.  In my 25 years of development, I've seen this happen time and time again.  Thus the result from such behavior is that companies simply stop releasing any information about the project's progress simply to avoid these issues.  It adds new meaning to WYSIWYG... in fact making it YGWYSWYSI (you get what you see when you see it).

In the spirit of the holidays, and simply to let people know things are indeed progressing I'm going to offer you three images.  They are not finals, they don't promise anything.  They are simply images of work in progress, no more, no less.  I don't know if I'll offer any further information or not.  It depends on my mood, Ron's thoughts and how people respond with regards to this current information.

Keep in mind these images are from a 1280x960 sized FS screen and reduced to fit within the pages of the blog.  That's why there is a bit of blurriness to the text.

Anyway, as I stated before... things are progressing well and I'm working hard to get the gauge system completed with all the features in place.  Most of the work involves line after line of code trying to implement abilities that FS simply doesn't have at all.  Always fun in that! ;)

Hope your Christmas was a good one and looking forward to the new year.