marcvc

I sure am... I have just started experimenting with migrating my Loupedeck setup from XMidiCtrl to Spad.Next; I really like XMidiCtrl, and it served/serves me well but I'm missing out on the more advanced features of LoupeDeck (like sending sending data back, updating what is displayed etc). That's what got me to DRT. Although the CL650 is my favorite plane, I haven't worked on it too much yet. Started off with some more simple planes I have (like the AFL KA350), to learn how Spad.Next works and how to link it to X-plane and MSFS (have done the BAE146 here).

No - sorry I was not clear. I meant I had to rename the DRT folder in the plugins folder from DataRefTool_v2.4.1 (as downloaded) to DataRefTool in addition to the setting up drt_ignore.txt with the entries below. Not doing so would make x-plane crash straightaway, irrespective of the plane.

For who it may help: in my case the problem was solved by removing the version suffix from the DRT plugin folder. I.e. I renamed the DRT folder in the plugins folder from DataRefTool_v2.4.1 (as downloaded) to DataRefTool and no more crashes...

Don't have experience with StreamDeck, but it will require a MIDI plug-in (just like with Loupedeck) through which you then need to setup your MIDI commands to go to XmidiCtrl; a quick google search gives e.g. https://trevligaspel.se/streamdeck/midi/index.html

I'm not using StreamDeck+, but Loupedeck Live which is a very similar kit (6 rotating knobs + 12 touch buttons and some more). I originally also used keyboard mappings, but found it quite cumbersome to set all those up in X-plane, and was also not entirely happy with the speed of the rotary knobs (too slow for some commands and too fast for some others). Then learned about XMidiCtrl, which is essentially a MIDI Controller interface into X-Plane. https://forums.x-plane.org/index.php?/files/file/76419-xmidictrl-a-midi-controller-plugin-for-x-plane/ It takes a bit of setting up (mainly on Loupedeck side, StreamDeck may be easier here) as well but I find it more flexible its use and it has solved the speed/lag issues with the knobs for me. It comes with an example file for the CL650 out of the box, but I have created a more expanded one that covers all FCP/DCP/CCP + baro controls. It works really well (also in XP12) - happy to share if helpful. Marc

Aha - thanks - learnt something new again

I get "INVALID CHANNEL" when trying to tune the ATIS frequency for EGFF @ 132.48 (tried both COM1 and COM2). (I tune into ATIS channel for all airports I fly into and this is the first time I have seen this)

Thanks - problem solved now. I run a manual (paper) checklist and was doing the "packs transition" one step out of order and therefore could not set a thrust limit (other than TO).

I had it too, right after packs transition during descend. No way to turn it back on. Incidently, during the flight before, after take-off, I couldn't change power limit to CLB, it was stuck at TO. Only after packs transition this was possible, but then a few mins later ATS quit as well. I wonder if something has changed in the interplay between bleeds and ATS... Only two flights so far and I ended up with a broken ATS each time.

I did my first flight with 1.5.2 and observed the same thing. ILS30 into ESSB After GS capture autopilot continuously oscillates between 0.55 and 0.65 AOA. Disconnecting AP immediately stabilises the descent. ESSB METAR ESSB 031520Z 24008KT CAVOK 07/M08 Q1003 Never observed this before.

Tried this and it works great. Thanks for sharing! Marc

First of all: this is a truly amazing plane – huge respect for what the developers have put together here! This morning I made a flight from LFPB to LFSB, with strong winds (as Eunice was getting close). At FL330, the tailwind component was well above 80kts for most of the time. The flightplan was created with Simbrief and winds were downloaded via de VHF link. The descent was done through VNAV, from TOD down to 4000ft – and all worked fine. However, I was surprised that I needed to (fully) deploy the flight spoilers pretty much throughout the entire descent in order to stay on the vpath and maintain 250kts (at idle, commanded by ATS). As all of that was programmed in the fms and the winds aloft were available (and verified on LEG WINDS screen), I would have expected that the TOD point calculation would have factored that in – and hence TOD would come earlier to allow for a descent without spoilers. Don’t know if that’s the way it is supposed to work in IRL, or whether I’m still missing some setup somewhere? Thanks, Marc