Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Graeme_77 last won the day on May 9

Graeme_77 had the most liked content!

Community Reputation

10 Good

About Graeme_77

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ozz, the usual cause of a "snatch" during AP engagement is the X-Plane flight director handing. Do you use flywithlua? If so, perhaps this little script will help you. It creates a keybinding called "Smooth AP engagement on Torquesim Islander". It works best with a long keypress, around 0.5 - 1.0 seconds. On the keydown it activatesthe (hidden) flight directors and resyncs the VS target, then on key release activates the autopilot - you should get a smooth engagement with ROL/VS every time. If it snatches, make sure your are in trim before attempting to engage the AP, and hold this keybinding for just a little bit longer. function activate_BN2P_autopilot1() command_once("sim/autopilot/servos_fdir_off") command_once("sim/autopilot/fdir_on") end function activate_BN2P_autopilot2() command_once("sim/autopilot/vertical_speed_sync") end function activate_BN2P_autopilot3() command_once("sim/autopilot/servos_on") end create_command("FlyWithLua/autopilot/BN2P AP On", "Smooth AP engagement on Torquesim Islander", "activate_BN2P_autopilot1()", "activate_BN2P_autopilot2()", "activate_BN2P_autopilot3()" )
  2. Thanks Ozz, I had the Carenado B58 in XP10 with the REP - I'm afraid to say I hated it - the logic was nowhere near realistic. The Islander is at least trying to do something like what the real thing does, the Carenado was behaving like a modern fully digital autopilot. The AP engagement logic isn't right at the moment as it remembers the previous VS rather than syncing. If you bind "Autopilot VVI Sync" and use than just before engaging the AP with "Servos toggle" the behaviour is acceptable. This has already been fed back to Torquesim - and all it really needs is a pitch mode engagement, then everything else would be more or less as per the real thing. In the absence of pitch mode "Autopilot VVI Sync" then "Servos toggle" immediately does the job. Further work on the ROL/HDG mode on approach shows the AP will drop from NAV mode to HDG when there is a VOR/ILS tuned, and from NAV to ROL when there is no VOR or ILS tuned. This is not correct, it should simply go to ROL when swapping between GPS and VLOC CDI. However, I feel that as the LR 530W does not show the required prompts that Garmin put there specifically for the KFC225 that the most useful behaviour may be to work on the basis the "swap and ROL" shouldn't be there, and allow the AP to maintain NAV mode provided there is a valid VOR/ILS source. This, after all, is what Garmin were trying to achieve anyway, within the limitations of the KFC225. Alternatively, if Torquesim would implement "external GPSS" where the AP would use the HDG mode (with a switch to swap between HDG bug and GPS) and simulate a fully analog control system then that may be more practical and more realistic given the constraints with the LR 530W.
  3. Having done hours (literally - it's 03:55AM!) more research on this, the KFC225 does support a form of GPS Steering. With the GNS530W in GPS mode it signals to the KFC225 to use the GPS ARINC 429 information to steer with rather than the analog HSI deviation, although it must use analog guidance for GPS approaches - see the link below. The KFC225 effectively can work in an analog or digital mode, and that mode is triggered by a pinout on the GNS530W. Now, for reasons apparently from the 1990s, when the GNS530W is changed between GPS and VLOC mode, the KFC225 will, IRL, drop back to ROL mode. So when the GNS530W is used with a KFC225 the auto-switching between GPS/VLOC must be disabled by the installer so it's always a pilot action to change over. You can read about here: https://www.twincessna.org/pdf/KFC-225-Internal-GPSS.pdf In the sim model, the GPS/VLOC swap is causing the KFC225 is going to HDG rather than ROL, but only in certain circumstances, as has been observed in this thread. That's not ideal - however setting the HDG bug to the inbound track during or just before intercept is a really good idea anyway, so by doing this you can mitigate the problem. I've got a bit more research to do and will update my bug report accordingly, but that will need to wait for a week or so.
  4. The GPS should not be able to “auto-slew” a mechanical HSI, the pilot must always set the course bar on the HSI to the GPS DTK value. Likewise flying an ILS it must have the course set on the HSI. The GPS drives the HSI, and the autopilot “reads” from the HSI, not the GPS. The BN2 as implemented currently does not require this (I’ve reported as a bug) but in general it’s a good idea to operate the HSI correctly. (That’s the reason the GNS gives you the next course and a countdown timer approaching the waypoint)
  5. @Goran_M i5-2500k clocked to 4.2GHz, 8GB 1600Mhz DDR3, 1GB Radeon HD 6850. P8Z68-V LE. (It was a good spec in 2012!) Test 1 :- All four sliders on the graphics settings to minimal, 1x AA. Loaded to an airfield outside the available scenery (runway and water everywhere) TBM Cockpit view 14.3fps, External view 23fps IXEG Cockpit view 30fps, External view 40fps Test 2 :- Visual Effects: High(HDR), Texture Quality: Medium, Number of World Objects: Low, Reflection Detail: Minimal, AA: None EGPH Runway 24, default X-Plane scenery TBM Cockpit view 10.5fps, External view: 14.2fps IXEG Cockpit view 27fps, External view: 29fps Default C172 G1000 Cockpit view 33fps, External view 30fps You've built a really, really beautiful model - but at the moment it's very heavy on system requirements.
  6. Thanks @skiselkov - I know your priority is making the model run well on new hardware and these older machines are a fringe case for you. Regardless a low poly model would be much appreciated. What I’ve seen of the model is really fantastic and hopefully in 6 weeks or so I’ll have a new machine to run it on.
  7. Skyguider your GPU is miles better than mine, but your CPU is of a similar age (I've got an i5-2500k 3.3 with a slight overclock). I've tried all the same things you did and can't get a significant improvement. I don't think it's textures as although they are 4K the total texture size is only around 200MB, My suspicion is it's the size of the obj files that is the issue, and perhaps that's loading the CPU rather than the GPU causing the whole sim to slow down. The obj files are enormous. 6 times larger than the IXEG, 5 times larger than Felis 154, 3 times larger than the FF A320 and finally only slightly smaller than the Rotate MD-80 which is virtually unusable on XP11 for me - although it ran OK on XP10 - again suggesting perhaps that the CPU load is the problem rather than the GPU. Here's a extract from an IXEG object:- POINT_COUNTS 7222 0 0 28056 VT -0.7237 0.3741 2.0096 -0.165 -0.439 0.883 0.6316 0.874 and from the TBM:- POINT_COUNTS 470814 0 0 470814 VT 0.00841901 0.09876074 0.00741016 -0.99862665 0.05215613 -0 0.894862 0.79924899 I don't know how the X-Plane engine works, but the sim appears to be being asked to draw a massive amount of polygons apparently to a higher precision with the TBM model. I'd be keen to see how your system performs if you swap the forward view to the X-Plane HUD view? For me this instantly doubles the FPS. No textures are unloaded, but the sim simply performs better without the cockpit view hence my suspicion it's the objects themselves. I've also tried pulling the CBs for all the G1000 screens but that has no improvement. As a last resort, I made a copy of the .acf then removed references to glareshield.obj, seats.obj, cargo.obj and cabin_rear.obj - this improved my FPS from 15 to 18 - a 20% improvement.
  8. Hello Javier, The normal way to do this on a single PFD+MFD G1000 is to use the Bearing pointers for the VOR. Click the "PFD" softkey and click the BRG1 and BRG2 keys to cycle through pointer options until you have pointers for NAV1 and NAV2 displayed at the same time. It's easy enough to fly a VOR "on the needles" rather than with the CDI presentation. Hope this helps!
  9. I've got lot less VRAM than that, but even with textures set to low and most of the internal and external textures resized down to 2048 there was no framerate improvement. I think It's all in the 3D model itself. If I go to external view and zoom far away or view forward with no panel the frame rates are fine and the pages like engine parameters are fine. From the TBM glareshield.obj POINT_COUNTS 470814 From the IXEG fuselage.obj POINT_COUNTS 81633 In the objects folder the IXEG has 137MB of textures vs 149M in the TBM - I don't think that's a huge difference for the GPU, but as I noted initially the TBM OBJ files are 6 times larger than the IXEG. (I completely understand my system is well below spec, and what I've seen of the system sim is really very good!)
  10. I’ve got a relatively old PC, I5-2500 and a 1GB HD6850 Graphics Card - and I know it’s probably well below what the developers had in mind when they developed the TBM so this isn’t a criticism of the product. However, I’m getting frame rates of less than 12 with the TBM, compared with 35 on the IXEG 737 with otherwise identical settings. I had a look in the objects folder and the objects are huge, the largest obj is 45MB for a glareshield. In total the IXEG objects are 56.5MB, with the TBM at 327MB - so I’m guessing this is where the frame rate hit is coming from. Changing the forward view to the X-Plane default HUD view restores the frame rates to 35-40. Before I commit $2500 to a new PC can I ask is any optimisation of the model planned? Thanks, Graeme
  11. I bought the MU2 in the recent sale, and it's certainly a tricky beast to master. The torque reaction seems a bit severe but I understand this is an MU2 trait and with practice not a issue. However one of those "little things" that looks a bit odd is how the digits move on the altimeter drum counter. Most commonly the digits are arranged on the drum so that as the altitude increases the digits move down in the drum counter window, just as they would move down the screen in a PFD display. However on the MU2 this is reversed so when climbing the numbers rotate up. Although there are undoubtedly examples where this is the case, in my experience the vast majority of drum altimeters work in the first sense. (For example the IXEG 737). My question is: is this an intentional feature based on the real aircraft modellled? If so, then that's great. If not, are there any minor updates planned where this could be changed? Thanks, Graeme.
  12. Jan, I've had a look in my earth_nav.dat file, and I have two lines for the ROVANI VOR. Line 9997 in the file, with a value of 6.0 before the ROI identifier, and another line 25306 with a value 0.0. At a guess I'd say one was the VOR, and the other the DME? I've checked my charts as well, and the inbound course is the reciprocal of the radial, so as far as the charts go the VOR should be correctly aligned with Mag North. Do you have an example of an instrument approach where the VOR is not aligned to mag north so I can have a look at how it's represented - I'm ashamed to admit I'd not considered that possibility!
  13. As far as I'm aware I'm using default data supplied with the Steam version of X-Plane. I've got the HD Mesh v3 and also the EFRO Scenery Gateway airport. I'll have a look at the dat files.
  14. Hi Kneighbour, Thanks for your suggestions. Flying a circuit in a 737 is not unknown, it's how pilots new to a jet transport learn how to land the aircraft before being released to fare paying passengers. That said, it's a very specialist kind of operation so I'll have a look and see if I can find any information on how it's done on the 737. It's a great idea though, should hopefully make for an interesting video. i've never seen the glideslope fail to capture, the only thing I can think of is it won't capture the GS until after the VOR/LOC has engaged. Also, I have a vague recollection that intercepting the ILS whilst in LNAV is not a good idea on the Classic, so make sure you pick up the localiser in HDG mode, at least until you're sure you can capture it every time that way. Would you be able to show me a screenshot of the flight deck when it's failed to capture? I'll need to see the EADI, EHSI and MCP in the pic. Thanks, Graeme
  15. Jan, Thanks for all your input on this matter. I've been doing a bit more investigation and based on the attached composite screenshot the VOR North value is exactly the problem. I don't see any problem at all with your Mag Vars and understand they're based on a 2020 epoch. Pictured is the default 172 tracking towards ROI VOR on Radial 180, so inbound 360. Nill wind and aircraft stabilised on track for a few miles. Note the Mag Compass value shown in the data output and directional gyro is 354.2, Almost exactly what the VOR North value for ROI is. Now what this means is the VOR "calibration" for want of a better description, is based on difference from Magnetic North, not True North. To fly inbound on Radial 180 I'm using a course from 354 degrees, rather than 360 as one would on a perfectly calibrated VOR. Now, to the root of the matter perhaps. I understand you very kindly updated the X-Plane Mag Var system (as well as all those lovely gateway airports!). As the VOR's are apparently referenced to Mag North, perhaps the values for the VORs were not changed when the MagVar table was updated? It's almost like the VOR North value was being used as a fudge to make the procedures work with the previous incorrect MagVar? If the VORs were referenced to True (i.e. had a VOR MagVar stored in the database) then perhaps this would not have been an issue. If I reset VOR North to 0 then everything works exactly as expected as if the VOR was perfectly calibrated. Thanks, Graeme
  • Create New...