tkyler

Yes and Jan mentions it and why...just a bit hard to hear I agree. -tkyler

Jan mentioned that this airport was not in the Aerosoft airport database (because it has no procedures)...and was simply demonstrating that we read the x-plane airport file in addition to the database data... just in case one were to enter a "small airport" as Jan did. The airport runway threshold data is given in lat/lon, which are, of course, very discrete points....so I couldn't say as to what causes the misalignment in this video, its certainly not ubiquitous. We have seen some issues with the magnetic variation and truth be told, there are probably some spots in code I specify true when the database data is magnetic and so we just have to find these one by one....but that should not affect "defined" lat/lon points like runway endpoints, only calculated ones, .....so it is something we'll investigate some time in the future. -tkyler

Indeed in most I agree. So I know some folks are curious just what takes our time...and Jan found yet another interesting bug that resulted in what we call a 'soft crash'....enough to cause the FMS to be useless in this scenario. So when you input route data (procedures), the FMS does all its 'calculating bizness' as you press the buttons, but when you enter a procedure for the first time in a new route, some variables like "true course to next waypoint" don't exist until the calculation has run at least once. Well the legs page shows these values and if you happen to have had the copilot CDU on the legs page while you enter say, a arrival procedure, then the copilot CDU tries to access these values so it can display it....and being they didn't exists yet, would cause a soft crash. The solution was as simple as testing if the values exist of course, standard stuff .... but unless you happen to have the copilot CDU on the legs page WHILE entering the first procedure of the route and WHILE doing so only in the air...you (me actually) would never see this bug because I rarely use both CDUs, except during ground testing and never try to enter data while in the air (need to be coding, not flying). Such is Jan's existence and thoroughness though, I am impressed what this guy finds. It will bode well for all of us I think! -tkyler

WARNING...Geek talk. The LNAV and VNAV calculations are deterministic, the 'performance database', is of course stochastic. The only way to get a fully deterministic implementation is to have air density and vector info predicted at every point surrounding the plane during the flight.....quite the CFD problem (and then some). For the given database input states to the routing algorithms, the output will be the same every time for the same inputs (numerical round-off notwithstanding).....as the calculations are fully based on Newton's laws. -tkyler

Indeed, there is quite a bit you can't see from the videos and screenshots...and also, its not just one or two folks, but 1000s that will trying all differing things, making for 100,000s of possible combinations that might be entered into the FMC. So while we are definitely not striving for perfection, as evidenced by our "whats not in V1.0" list, we do have to ensure that the basics desired are in. To elaborate further, the "desired basics" are those FMS functions that We ourselves as simmers have always said with other products, "I wish the FMS did X....or Y, etc. It turns out the X and Y is a pretty long list of stuff and you take for granted just how many things, as a coder, you have to account for. For example, I'm going to throw Jan under the bus here a bit to illustrate. Jan tells me once, "cruise phase is always in mach". Ok...cool...I made that happen. THEN...a good while later, Jan flies a flight with a cruise altitude under 10,000...where the speed restriction altitude is 250 kias. Jan comes back...."hey Tom...these cruise value should be in KIAS"........"OH...so you mean cruise phase is always in mach, except for condition A.........um....is there a condition B I should know about too? A C perhaps?" Sorry Jan! So things from a coding perspective are not as simple as they may seem on the surface. While maybe 95 out of 100 flights will probably never use cruise altitude below 10,000', some will..and we have to anticipate that before hand and handle it. It turns out there is a whole lot of these situations. The good news is that we believe our V1.0 FMS feature set is complete and we are "testing/calibrating" the performance while we simultaneously clean up textures, loose ends and docs. -tkyler

VERY

NavDataPro / Level D (xml) ..and the offending data lines: <Name>OM26</Name> <Type>Normal</Type> <Latitude>51.872750</Latitude> <Longitude>11.540094</Longitude> <Speed></Speed> <Altitude>3000</Altitude> <AltitudeCons></AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction>

I don't like using the term "bug" in this case....it results from the NavData database where that WP has a altitude restriction of 3000, which is too high for its proximity to the threshold. If you miss this tidbit when inspecting the legs page and fly the descent, you'll be quite high and probably miss your landing. We've seen this on several airports and you just have to inspect the route "vertically" if you plan to use VNAV, apply some basic rules of thumb and then edit the route accordingly. -tkyler

well here's a little report, just so you know we're not sitting around doing nothing. We are polishing up lots of little corners many won't see. As I said, the reason we are doing so is not a matter of pursuing perfection, but rather is because when you put this in thousands of hands, they will find these issues and if they cause crashes, that is no bueno as we like to say here in San Antonio TX. So today, I was addressing parts of the N1 limit page, for derate stuffs. So here's a CDU entry pattern you probably don't see much. Say you select "TO-1" derate....that will automatically select the "CLB-1" derate mode (so the throttles do not advance in the transition from Takeoff to climb phase....Boeing says that confuses the pilot dontcha know eh?). And then lets say you enter a assumed Temperature value....well depending on the temperature entered, that too might automatically derate the CLB thrust, not only to CLB-1 mode, but maybe CLB-2 if its hot enough......so far so good. But then lets say you decide to delete the TO-1 mode....well the CLB thrust mode may or may not revert to one of the reduced mode..... or not dependent on the assumed temperature entered.....and there are a myriad of other potential combos that may or may not get entered. Here's a little video to show several different combinations that have to be tested....and there are quite a few more patterns other than what is shown here. https://dl.dropboxusercontent.com/u/955680/n1_limitOPT.mp4

we certainly want to encourage that kind of 3rd party interaction with the 737 and do plan to publish datarefs/commands as needed. We are wanting to start a dedicated forum just for "interfacing geeks", where cockpit builders and other developers can discuss how to go about doing things and what is needed from IXEG to facilitate such efforts. -tkyler

It is not lost on use to simulate every little "effect" due to every possible input by every possible system, but the thing here is simply the "volume" of things to be dealt with. Being this is our first product, in order to be competitive, we really have to achieve the same technical level as a 17+ year old company with more resources and experience and well....that is just taking a while, especially given that we're a 4 man team working in our spare time. This is a testament to using Gizmo and its vastly reduced compilation time. It is our belief; however, that once we get this initial tech on the market, we can then expand upon the smaller details and try and capture as much of the real thing as possible. Rome wasn't build in a day, nor in 5 years. In time, we'll refine the 737 and eventually, get to that vision we have. Its enough for now just to get a really robust FMS / AP implementation, which is priority 1. -tkyler

Hard date estimates are too tough...but as an eternally optimistic kind of guy, what I can give you is a "hey, it would be awesome if we could have something in X weeks". Then when we get to that day and we're not there, I'll say it again, "it would be awesome if we could have something in X weeks"....and if we don't make it then, we'll do it again and again and if we're steadily moving closer to our goal, then one day, the estimate will converge with reality. I don't care if I have a moving target as long as the delta between me and the target is always closing....that math adds up to convergence at some point if you go far enough....the trick is to get there. This is the way I find my motivation to push on, I always have to believe I'm close enough to keep moving...and if thats what it takes to get this done so we can all have this sim experience, then it is what it is. I understand other folks would do it differently, but hey, they're not doing it now are they . It would be awesome if we could have something in 5-6 weeks wouldn't it? -tkyler

Ok, here's a real report. In the last few days, we have seen very, very few gizmo crashes (from my bad programming) with regards to FMS work. There are a few fringe cases, but they are getting very tough to reproduce and usually come about when you start punching buttons like that kid in the movie, Airplane 2. ...stuff most of you would not do. In prep for the final steps before letting beta folks test it, I have refactored (programmer speak for "cleaned up") the code to be more user friendly towards VNAV predictions and debugging VNAV performance values......and that is what we are currently working on. If you don't plan to use VNAV, well I'm sorry, the FMS was ready for you a long time ago....but once you do learn it, and it actually works as expected, its quite satisfying and fun to experience....hence our efforts to really make it work. So tomorrow I'll be flying some test routes to fine tune the descent code....and if all goes well, we want to let the beta testing folks have a hand at it asap. I think Jan is planning a "full flight" preview, but no promises, I can't speak for him, he may not have plans for that. (no micro-management here). Now I know most folks automatically assume that once a closed 'beta' begins, that will uncover a slew of other bugs, which adds to the development time, but I have to tell you now...that I have NEVER seen a tester like Captain Jan Vogel! (He IS that kid from Airplane 2), except with 100x the knowledge (very dangerous). This guy finds stuff that nobody will EVER try. and when this guy says, "its good for V1.0", then I will challenge the beta guys to find something we don't already know about. Now note I said, "know about". We know there's holes in the FMS, but feel its getting to the point to handle a good 90+% (or better) of use cases. If you are that super hard-core simmer that likes to explore the fringes of FMS usage....well...I'd say, "fly some normal routes first or wait". Work continues daily! -tkyler

1. Fly approach to EDDF, ILS07C.....execute missed approach to TAU VOR 2. Fly approach to ILS07C again...miss it again, divert to EDDK....missed approach there 3. Divert back to EDDF, ILS07C 4. Just before IAF, change arrival to runway 07C with 19NM runway extension waypoint and bank hard right to catch the extension waypoint and bleed some speed, then hard left to reintercept the leg between the extension waypoint and 07C threshold. VNAV calculations got a bit off during this little test, what with all the CDU shenanigans going on, but the FMS didn't crash....quite the plus. For normal flights without missed approaches, everything is performing quite well. VNAV calibrations continue. -tkyler

I confess, I took a week off and went to Germany and Zurich for some R&R. Pressing CDU buttons 1000 times a day got quite old. I am back though and we are moving through the bugs we find reasonably well. We made good strides yesterday and today I am flying several missed approaches to test CDU entries during that phase when you want to refly the approach. Yesterday we tested short routes....like 25NM short with high cruise altitudes where you can't make the cruise alt but still have to transition the aircraft from climb to descent at some "intersection point" between climb and descent paths. So these really fringe situations must be explored as they can be entered and can crash the simulation if not accounted for. So we only have a few things left, but they take quite some time to test properly as we are all finding out. Its common to fly a 25 minute flight, discover a bug, fix the bug (sometimes a simple typo, other times not) and then fly the route another 25 minutes to verify and then try a similar route somewhere else just to make sure.....so 1.5hrs of time lost to a typo. (actually happened....had a dash instead of an underscore for a variable name). And if the bug is more severe...then it can take half a day or more to track it down due to having to monitor so many variables during a flight. Oh well, we keep going. -tkyler

Depends on which 737, the winglets were a bit different for a few of the models. ...and it also depends a bit on the angle of the view as to how they look, I can say unequivocally though that I'm done debating it (did that enough with my team members) or willing to change it . -tkyler

It will not at the onset. I have not yet programmed in support for manual waypoints of that format...PBD, LL, etc. I don't think it will be difficult to do so, but I'm not on that task at the moment, plenty in front of it. Once I do get that put in though, I would suspect that adding support for that type of point should be doable. And as far as PFPX goes, I think it supports *.flp format (not *.fpl)...which is a format we do read in. In fact, I think someone asked the question of supporting PFPX some time ago that caused us to want to import multiple file formats. There is no format that we could not probably write a importer for; however, some formats are just too verbose for us to want to even try.....and many formats encode the waypoint data within the file itself whereas we rely on just the names, that is 'what you would type into the CDU'. You give us names, we pull the data from our database and build the route, etc. The ideal format is *.fpl IMO. -tkyler

Added support for *.fpl format (as opposed to flp), which is my favorite format, very short and clean https://dl.dropboxusercontent.com/u/955680/fplSupport_opt.mp4

I'm not sure where this was mentioned...I'm pretty cognizant of what we've said and when we've stuck our foot in our mouth (which we have) and we did say we want to do tutorial videos....but I'm not sure we ever said we would do these prior to the release...or even the manner of the release....not to my knowledge anyhow. It is NOT correct to assume that the release of any videos is any gauge as to the timing of the release of of the 737. We are doing veracious QC testing atm and will release in due course as our requirements are satisfied. -tkyler

As Jan says, DCL is for debug only; however, I think other FMS systems may utilize it. (Hrm..small bug uncovered. The wrong waypoint is Magenta :P) See...still a tiny bit of work to do NOTE: Before we get in too deep....theses points are not absolutes.....except maybe the first T/D. You cross that first T/D circle and the plane enters the decent phase. The other green dots are "estimated" of course and depending on lots of things...like our performance database, winds and such, the plane may respond a bit on "either side" of these markers...but they are, in general, close....or should be. Its one of those things we expect users to help refine if we missed anything. Here's the correlation.

Flying descents nicely now.

Once you are 'out of bounds' of the route parameters, you are right that things go bad very fast. The most difficult situation is when you are past the Top of Descent point and you simply cannot make it to the runway following the procedure without flying too steep and with flight spoilers deployed and even then there is no guarantee depending on how "late" you are past the T/D point. Simply said, in such a case, you can NOT recover and still fly the given procedure, you have to extend your descent distance somehow by flying off route. Jan does this in one of his videos where he "circles back" and rejoins a procedure leg. (ala pattern work) Also, It could be your arrival procedure has some restrictions that cause you to fly level segments and if you can get ATC permission to bust the restrictions, you could make up some ground and descend on those legs. I have actually spent the last few weeks working on these more difficult scenarios...what to do "IF". As Jan mentioned...as a professional pilot, he has never seen some of these situations, but for newbies like us, we get into trouble all the time and so the FMS has to handle really odd inputs sometimes. There is one thing to note...and that is that the flight profile does have bounds....and the FMS is not a "save all". You get too far out of bounds and the FMS will do no good or give you bad results. BUT, I can say firsthand, that is why I myself keep at it....to get it right. It is addicting. I flew my very first completely automated flight yesterday, takeoff to touchdown with speed and altitude restrictions on climb and descent...all the way down to minimums, the ultimate milestone. All I did was raise/lower gear and flaps after engaging LNAV/VNAV. So whats left? There are still other scenarios we have to punch in to see what happens. Short routes, half routes, changed routes, changed destinations etc. Of course we have coded for these, but we are testing them now for stability and patching holes as they arise. Good news is the bugs are getting much fewer and far between. Stability testing with a broader group is up next. -tkyler

noted...and the value thereof. We will look into those features at the appointed time. Hold and offset probably the easier...TCAS tougher, not so much because of vector algebra, but rather getting the data of each aircraft. Besides....if we get TCAS, whose to say the other aircraft won't have a good implementation and the next thing you know you're crashing into each other anyhow. OR perhaps you mean TCAS in a simple "2D top down view" simply to avoid other aircraft laterally? As opposed to full blown "instructions" from the computer. -tkyler

on the very near term todo list!

So on another note, quite a bit of a milestone. All the code for the VNAV 1.0 feature list is in place as of today and we are beginning flight testing and debugging of the full route LNAV / VNAV capability within a few days (our main tester seems to be a real airline pilot away at work....slacker). After our internal debugging checks and fixes, we'll engage a relatively quick beta test with some selected newbies (already selected)...and then we will mop and sweep, spit and polish and release. No date given. -tkyler