Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by tkyler

  1. another peek of the business end of things.
  2. Actually I've been rethinking the 'complete rewrite'....but I should mention there there are two significant rewrites planned. 1). the VNAV algorithms and 2) the XP1100 Navdata integration. Originally, the idea was the XP1100 navdata is of a format that would make LNAV route building a bit less painful (being only one format instead of 2, i.e. Navigraph and Aerosoft)....and a reliable lateral route is required for a successful vnav calculation.....hence combining both heavy rewrite tasks into one activity; however, we've seen enough success with the recent LNAV route building....that we fe
  3. A bit more progress on the cockpit. The window trim proved to be really difficult to get lined up where everything looks "proportionate" with all the reference pictures / angles. But with those out of the way, things are moving a bit quicker again. The panel shown here is th legacy panel, not the new one...so that also will get a "detail" makeover. -tkyler
  4. Also, a clarification between depicting the published restrictions vs. honoring those in our VNAV calculations is warranted. Previously, we did not even show the restrictions correctly on the LEGS page....and that is a separate issue from a VNAV calculation where you have to assess those restrictions with other paramaters and ultimately calculate the altitude for a waypoint. As Jan says, the VNAV rewrite we're doing will address the issue. -tkyler
  5. working on it as we speak. Work on it IS in active rotation and its priority. -tkyler
  6. There is no power button on the copilot side Avitab. Since the avitab screen is shared between both, and 99%+ of users fly from the pilot side, we didn't want a copilot actuation of a power button to shut down the pilots side (in the case of a shared cockpit). Are you encountering the same issue with the power button on the pilot side Avitab? -tkyler
  7. Thx Gents. Both these errors (legs page) and the #503 errors are fixed and in the next patch. -tkyler
  8. The error message pertains to the LEGS page "drawing function", which means you were showing the LEGS page on CDU2.. Indeed I can recreate this error if I put CDU2 on the legs page and then repeat your procedure! Lucky you were on the LEGS page (sort of). Thx for finding and reporting. Its already fixed for the next patch. -TomK
  9. Thx Tim....we've seen one code break already and I'm already looking into that fix. I am quite driven to make this very reliable and accurate and user tests/inputs such as yours are. a great help. I'm committed to hunting these down as soon as they're found! -TomK
  10. Thank you gents. Its amazing to me that diversity of situations that you find that we just can't seem to locate ourselves. I will jump on this asap; however, we've had a death in our immediately family I'm dealing with the remainder of this week, but will return to debugging these straight away. With the rewrite out of the way, I do not expect this debugging to take long. Thanks so much for reporting. -TomK
  11. In order to build the thing in 3D, I created some drawings of my own that I could probably develop a bit further for you (and corroborate with Rob Archer) and send you a DXF or DWG. It may take a week or two as I'm traveling about for the next 10 days. Alternatively, I can get you a really high rez orthographic rendering of both our panel layouts when you can probably scale the dimensions off of somehow knowing a reference dim. That I could get to you pretty quick. -tkyler
  12. I have to admit, if I was going to be a phiser, then without a doubt, I would absolutely use Gizmo Beta Version as bait to get folks to click on it. I bet every one on the planet is tempted to get them some of that Gizmo beta. its much better than those lame phishing offers of winnings, or money, or completely undesirable stuff like that.
  13. Another weekly update. The rather rigorous testing of route editing over the last week had brough forth a few more issues, not unexpected during such a substantial rewrite though... but without a doubt, there are substantially less issues with route editing. Jan's last round of route testing, he was unable to get a gizmo crash when changing procedures aggressively and could swap any procedure at any time. Our goal here is for folks to not be scared of to push any buttons on the procedures page during descent / approach for fear of a gizmo crash, and be confident they'll get the route they
  14. Ok..another week gone by. 60 more hours of rewrite on the FMS route editing and guess what, we're still easily 95% of the way done Seriously, we are into the more hardcore route editing features now, the really fringe type of data entry patterns...changing your mind "mid transition" selection for example, or selecting a STAR, then approach, going to other pages, then coming back to select another STAR, then TRANS, then swap to a runway with an extension, then shortcut points, etc. Testing earlier in the week had us redesign some other algorithms and we figured we should just power thro
  15. how repeatable is the event. Does it happen at exactly the same time? or about the same time? etc. Also, if you can repeat it and then post the X-Plane log file (Log.txt in the X-Plane root folder) that would be a good data point also. -tkyler
  16. Hello all. What started out as a 'quick bug fix" for our annoying gizmo '470' error has, over the last 80 hours in one week..... turned into a very significant rewrite of our route procedures editing code. I was hoping to have it done by this weekend, but we are not quite ready. We are easily 95% of the way though and will continue to push to get this rather significant FMS update out asap. Depending on the routes you enter, some may not notice much difference, but for others, the difference will be quite noticable with the "routes editing as expected". Of course there is no way we can t
  17. Many procedures are "mated" to runways. On the Beoing 737 NG, if you select a runway that is not mated to a currently selected SID, you will get a message "RUNWAY N/A FOR SID:" The FMC will then make that runway the selection, delete your SID waypoints and filter the SIDs list for you to select a 'matching' SID. Conversely if you select a procedure that is not mated to the currently selected runway, the message then reads: "DEP N/A FOR RUNWAY" ...and the FMS again selected the SID, dumps any previous procedures and filters the runway list for you to select a mating runway, We n
  18. Jan is right, we have not touched the AP or VNAV code at all since 1.21, so if something is worse, we need to know exactly what it is that "makes it worse". Debugging is quite tough business, not so much the fix, but the amount of diligence it takes to quantify what the issue is and put it into words. Good VNAV starts with good routes to make calculations from, and that is where we currently are as of this instant, fixing the STAR / APP route building code as these procedures are selected...since they are clearly resulting in 'funny routes' where VNAV calculations make no sense. That '
  19. Ok...fixed. here's the deal for the curious. one darn character I have code that evalutes scratchpad entries to see if they're user created. For Lat/Lon types, the format is latitude letter (N or S) followed by number, then a longitude letter (E or W) followed by more numbers. My parser looks like so: [NS]%d*[EW]%d* The problem? using an asterisk allows "no results" to be valid....so this pattern doesn't require any numbers to be between the letters, so SEA for example....the parser is finding the S and the E...and thinks its a Lat/Lon point. Same for CRUSE or ANY way
  20. Thx, specific experiences / routes vs expectations regarding these altitude restriction issues are very good data points for me. Thx for the input. -tkyler
  21. This is a lengthy post, explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here. This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate. It was from Navigraph. The first thing I did when I started was to open up a few XML files to get the lay of t
  22. so digging a little deeper, I now recall why I had that line of code in there...and why we need to switch over to the XP1100. nav data format. The problem is the XML format we use does not represent "common" portions of STARs such as is found at KBOS. In this particular example above, the STAR serves 'all' runways, indeed that is the exact word the XML format uses for this star..."ALL". BUT at an airport like KBOS, a STAR will serve a bunch of runways and perhaps only the first few points of the STAR may be common before it diverges to specific runways. So if a runway was NOT selected, b
  23. Not necessarily. If you dig into your fmc_data > SidStar folder inside the IXEG folder and pull out the ENGM.xml and EDDU.xml files and post them here, I can try to reproduce this with your exact dataset. It is definitely worth trying to reproduce for me as I would not expect that bypass calculation. -tkyler
  24. For the life of me, I have a line of code that says, "if the arrival runway is selected, append the star transition points". I remove that condition and everything snaps into place on this particular procedure (still a tweak to RTE page required though). I can't recall what kind of situation made me put that in all those years ago (though I'm sure some other user will find it). Transitions were particularly challenging given the XML dataset I originally started with, that I do remember...and one provider had runway transitions and another didn't. Things seem to have leveled out over the
  • Create New...