Jump to content


Popular Content

Showing content with the highest reputation on 10/17/2018 in all areas

  1. 3 points
    Captains, After more than one year of full time development I am pleased to announce the TBM-900 is on short final and will be ready for your hangars this weekend! Releasing Saturday at Midnight Eastern Standard Time (get ready to hit that buy button Friday night!). The TBM-900 is the most complex turboprop aircraft simulation produced for X-Plane to date, and one of the most interactive of all aircraft ever produced up till now. We truly believe this will make for a very exciting experience as you fly through the skies! Because of the complexities of the aircraft, and the fact that text is not always the most fun way to digest information, we will be doing a daily 1 hour livestream video session. Each day we will announce which time it starts, with the first one starting in just a few short hours today at 6:30 pm EST (2230 Zulu). You can watch the livestream by clicking here! (Previously Recorded) A brief run down of the core feature list is here: Heavily multi-threaded systems architecture to leverage performance of modern CPUs with many cores.  Flight model tuned to perform to within a few percent of the real aircraft in the normal flight envelope, including maximum and stall speeds, rate of climb, fuel burn, trim behavior and control feel. Full aircraft state persistence. Every switch, flight control position, fuel state and on-airport position is restored upon reload. Even between reloads, system resources change in real time. The engine and oil cools down slowly between flights, the battery drains, tires slowly deflate, etc. Fine-grained systems model, down to individual sub-components. The always-on failure system realistically responds to wear & tear and overstress for each sub-component based on individual load factors. Over-torque, over-temp, frequent starts, hard landings, operating in FOD-contaminated environments and many more all affect individual sub-component wear & tear and service life. Sub-component wear realistically reflects on aircraft performance. Worn engine parts reduce maximum available power, worn prop reduces top speed, worn tires result in worse grip during ground ops, etc. Aircraft maintenance manager to inspect and repair or replace any damaged sub-component. The maintenance manager tracks per-airframe operating expenses in a realistic manner to show the real cost of operating the aircraft. Airframe manager that allows you to operate multiple simulated airframes, each with their own independently tracked wear & tear, livery selections and custom registration marks applied. Airframes can be automatically synchronized between multiple machines over the network with just a few clicks. This automatically syncs up aircraft position, configuration and wear & tear to simulate multiple users sharing the same physical aircraft. See how your fellow pilots treated the aircraft by checking the maintenance manager and engine trend monitoring outputs.  X-Plane 11 G1000 avionics stack with lots of customizations and overlays to simulate the special extensions in the real TBM900. This includes a custom EICAS, systems synoptic pages and special integration with the extra simulated systems such as the weather radar, TAS, electrics, etc. Integrated Synthetic Vision into the PFD with obstacle display, navigation pathways, airport labels and TAWS-B integration. Integrated live charts display from FAA and Autorouter.aero. Navigraph integration will be available in a future update. Fully custom electrical system. Simulation of all buses, switching behaviors and reconfigurations. Full circuit breaker system, integrated with the X-Plane failure system, so a failed or failing system can pop a breaker. Highly accurate PT6 engine model with realistic startup and operating behavior. Engine lag, secondary fuel flow, ITT evolution, response to auxiliary load and many more fine-grained behaviors. Custom prop governor, with all modes simulated, including electric auto-feather with negative torque sensing. Crew Alerting System integrated into the avionics stack with all annunciations, takeoff/landing inhibits, flight state filters and "corner cases" simulated. Environmental Control System integrated into the custom EICAS. Air conditioning and pressurization respond in real time to environmental factors such as ambient temperature, pressure, available engine bleed air, cabin temperature setting, cabin pressure vessel failures, etc. Custom TAWS-B ground proximity warning system with all annunciations modes, inhibits, real-time impact point prediction and terrain painting up on the MFD to ranges of 200NM. The TAWS-B uses the X-Plane terrain DSF data to construct its database, so it is always "up to date".  GWX 70 weather radar with weather & ground modes and realistic radar return painting. Full simulation of radar beam energy dissipation, signal attenuation when passing through dense weather and vertical cell analysis modes. Terrain mapping accurately paints surface features, including recognizable peaks, valleys and lakes. Supports the X-Plane 11 default atmospheric model as well as xEnviro. GTS 820 Traffic Advisory System (TAS) with aural alerts + visual alerts, the TAS MFD page and compatibility with X-Plane default traffic, PilotEdge, Vatsim and IVAO. Full simulation of the ESI-2000 standby instrument, including all configuration pages, sensor failures, AHRS drift and "roll-over" during extreme maneuvers, realistic battery operation and real-time battery depletion, etc.  Dynamic custom registration mark paiting on the fuselage and instrument panel with support for custom TrueType fonts, colors and positioning. This lets livery painters make a "generic" livery and each pilot apply their own custom registration mark with just the click of a button directly in the simulator. Liveries can specify a custom position and font to optimize the look. Custom sound engine with samples from the real aircraft and accurate modeling of individual engine states and sub-component noises such as fuel pumps, gear pumps, flap actuators, etc.  Now, let's roll onto our first day of systems overview briefs we will be doing up till release day! From the start, we have been focusing on making the aircraft "feel" like a real machine. And if you have dealt with real aircraft, you will know that they can be moody at times. Sometimes the engine starts on the first try, sometimes it just seems to want to drag its feet. Other times, you come up to the aircraft and the battery is strangely low, so you need to sit on the ramp after engine start a bit longer to let it charge up. While working on the core systems model in the TBM900, we have taken a great deal of time to focus on getting this kind "personality" coded into the aircraft. Looking at the above image, a watchful eye can immediately see that the "ITT" display is reading 18 degrees C. But the outside air temperature is just 15 degrees C. That slight discrepancy can be due to a number of factors. It could be a sensor inaccuracy. Or it might be some residual heat from a previous engine run. To provide such minute effects, under the hood the systems simulation actually breaks the engine up into tiny pieces and models heat flow between them. Normally those kinds of details would be inaccessible to the end user, but we have decided to go in the opposite direction. We will not only let you see the system details, we have built-in analysis tools for you to examine systems behavior in real time. All of the fields you see above are clickable and can be displayed like a graph of the last 10 minutes. While flying aircraft, we tend to forget about all the complexity that happens behind the scenes. We push a button and things just happen. But with the analytics screens built into our model, you can get an appreciation of what goes on inside the machine to make things go. Let's go for an engine start. We will skip most of the boring part of the engine start, that is the initial motoring and come right after fuel introduction. You can see that the engine has passed its critical "hot" point around 30% NG, but to help you visualize the engine model, I have brough up the ITT and Turbine temperature graphs. You can immediately see how the turbine temperature lags behind the ITT. That's because the ITT is the temperature of the exhaust gasses, while the turbines themselves contain quite a bit of mass of metal that needs to be heated. As the engine accelerates, you will see a double ITT spike that is very characteristic of the PT6 engine. No other aircraft model that we're aware of reproduces this correctly. The second ITT spike comes because the engine start is actually performed in two steps. The full fuel flow required to start the engine and bring it up to its low idle condition is too great at the low engine speeds. It would simply cause excessive engine temperatures during starting, which would significantly shorten component lifespan. So instead, the PT6 (and many other turbine engines) contains "duplex fuel nozzles". As you can see the fuel nozzle has two circuits, a small primary (darker green) and a larger secondary (lighter green). The primary is rigged with a flow divider valve that is spring-loaded to actuate above a certain fuel pressure. This is calibrated so that once the engine reaches 42% NG, the fuel pressure exceeds the spring tension and opens up the second fuel port and allows more fuel into the engine. In the TBM this manifests as a sudden rise in fuel flow from approximately 18 gallons per hour to 25 gallons per hour. There is also an audible rise in engine acceleration. The observant among you will also no doubt have noticed that the ITT display on the EICAS (Engine Indication and Crew Alerting System) is different from the graph value. The reason for that is rather simple if you think about how real sensors work. The sensor surface itself is a metal stud inserted into the gas flow. As such, it too takes a bit to warm up to the real gas flow temperature. In addition, the sensor is an analog device. There is an analog-to-digital conversion circuit that samples the sensor reading and since real sensor data contains some noise, the sample does input "filtering". In simple terms, it doesn't show the immediate value from the sensor, but instead gradually "filters in" the value sampled into an old reading. This provides output smoothing and a much more stable output value. So always keep in mind that what the aircraft's sensors are showing is probably a couple of seconds old anyway. In the next post tomorrow, we will focus a bit more on avionics and some of the cool features we have developed in that department. Stay tuned, and we look forward to seeing you in the TBM filled skies this weekend!
  2. 1 point
    While it is difficult to make exact estimates on framerates, an i7 4790K should be able to handle the aircraft avionics with ease. Most of the heavy lifting of the avionics rendering is shifted away to background threads, so even my piddly i5 4460 that I develop on was able to do a locked 60 fps while streaming yesterday. Of course, this was in an area with little scenery. I would say your performance will mostly be dictated by the scenery and your GPU horsepower, rather than being limited by the aircraft's systems code and CPU speed.
  3. 1 point
    I'm happy to assist others in writing one, but I don't plan on doing it myself. While I would consider shared-cockpit a core feature requirement for an airliner, the TBM is almost never flown multi-crew, so that puts the feature rather low on the priority list from a realism perspective. And a second reason is that the airplane runs tons of randomizing code that gives it the "organic" feel of every flight being different, every system responding a little different to inputs, etc. Replicating that between two nodes would be a major undertaking and I'm not really sure is even practically possible (at least to my requirement of stability & usability) by using smartcopilot's simple dataref syncing approach. I suspect it would take a much more integrated approach that would talk to the internals of the systems simulation directly.
  4. 1 point
    So as you fine folks may already know, in our usual style of going completely overboard on the level of detail, a few weeks back I've implemented a custom VHF radio signal propagation model. This means, NAV radios (VOR, LOC, GS and DME) are all simulating things such as terrain masking, terrain diffraction, tropospheric scattering, etc. The underlying computational model is based on the NTIA Irregular Terrain Model (ITM), an industry-standard model used for things like radio tower planning. The simulation includes a built-in analytics display that allows you to check the terrain profile being used by the radio model (please note, the image below isn't hand-painted, it updates in real time as you fly): What's recently new is that I re-implemented the ADF and standalone DME radios as well. So the entire radio complement in the TBM is as follows: Two VOR/LOC/DME radio. One ADF radio One standalone DME radio That involved re-implementing all course deviation needles and the DME tuning pages on the PFD. All features of the real G1000 are simulated, even some of the more odd ones: ADF, ANT, ADF/BFO and ANT/BFO reception modes. This is reflected in the audio ID portion, including the continuous tone you hear in BFO mode when no ADF signal is being received. All DME tuning modes simulated, so NAV1 slaved, NAV2 slaved and HOLD. Allows for flying the more bizarre approaches, such as NDB/DME. Intercom audio routing from the radios is properly implemented, so NAV1 & NAV2 buttons route the audio ID for the NAV1/2 VOR/LOC portion, the DME button routes the standalone DME radio audio (including 1250 Hz square-wave tone, instead of 1kHz sine wave) and the ADF radio routes the ADF radio audio (including proper tone & background noise behavior depending on reception mode).