RXP

Hi, Just put your mouse over my pseudo image to the left of my post, and after a few seconds when the popup shows, click "Message"...

I'm glad you've sorted this out, even if this required downgrading the driver only because of the known XP11/VK/AMD issue. Let's hope they'll update their drivers and cure this in the future.

@Schwokol I've moved your post into the relevant topic. Please make sure to follow the recommended posts at the top to get started.

Hi, can you please send me your purchase order # in private message?

Hi, What the tutorial shows is that: - The GNS plugin can be configured to display/render the GNS device with or without a bezel - It can also be configured to render on the 3D cockpit at the same time it is rendering in a popup window - It can also be configured to render at multiple locations in the 3D cockpit at the same time. This is implicit given the naming/configuration scheme which tells it renders into any location you're defining in a dedicated section in the ini file. - The user's manual p14 footnotes also confirm this: Please note you can only configure one window per gauge, but you can configure multiple panels per gauge. Having said this, the X-Plane SDK doesn't makes it easy for end-users because there is no facility included to do so. Therefore, our plugin offers the mean to manually configure all of this in the .ini file, and it takes care to render wherever you're telling it to render to. This also means there is not "automatic" or "easy" way to configure the GNS into the 3D cockpit, although after trying a few times you'll most likely find out it is not that hard either. You might want to start looking into the "Official Panel Configuration" pinned topic for many different ready-to-use configuration files shared by other customers. This might help you get the gist of it faster. Now regarding the RealSimGear hardware, from a GNS configuration perspective, these are nothing else than another monitor connected to your computer onto which you'll display the popup window. This doesn't change the fact that a popup window won't magically duplicate itself onto the 3D cockpit though, and for this one, you'd still have to configure the .ini file to do so. As for the CDI button, I don't know what you are referring to as "the alternate indicator/button". If this is something specific to RealSimGear you might want to contact them about this. However, the GNS CDI mode is designed to sync with the simulator equivalent NAV/GPS switch and it can be configured in different ways. Some aircraft might be "enforcing and managing" the CDI mode on their own and I'd suggest you review the CDI mode setting description in the RXP GNS User's Manual to learn about this configuration option (and all the others, there are many).

Hi, Just 1) download and run the latest e-commerce installer form our website 2) enter your F1 account credentials 3) press the REINSTALL button.

Hi, There are plenty of topics about configuring the RXP GNS V2 in the 3D cockpit, starting with the pinned tutorial (also included in the RXP GNS User's Manual): You might want to review ALL the other pinned topics as well!

this looks like a known AMD driver problem that comes and go depending on the driver versions unfortunately: https://community.amd.com/t5/drivers-software/radeon-21-4-1-breaks-x-plane-11-plugins/td-p/467998

Hi, Thank you for the screenshot, this is helping a lot to understand what the problem is! This is not supposed to display like this even with in VK. What is your video card brand/model and driver versions?

This would mean Carenado has hard coded the 750 model in their detection, instead of a any 7XX. If there have just coded the visibility of the 3D bezel based on our published datarefs in the 3D model only (not in any additional plugin/logic), you might be able to manually edit their "cockpit" .obj file with a text editor. This should look like something along these lines: ANIM_BEGIN ANIM_HIDE 1 1 RXP/radios/indicators/gtn_unit1 But I believe there are 2 sides usually: the 3D model hide/show logic like above, and the plugin logic for the rest.

@rodders1947 Hi, the error message during installation can be safely ignored like you did. A few other customers are also having the same message during installation and so far it doesn't seem to have any incidence on the product operation in the simulator. However I'll repeat myself: the GNS trainer can't run standalone. This is not a bug, it is how it is.

I really don't know why you are repeatedly trying to argue instead of finding a solution. It looks like despite my best efforts (giving you the page number of the user's manual) you are still not reading it, or the information is not clear enough, so just to make sure at least others reading this discussion know what you're failing to read so far, I'll copy/paste the User's Manual relevant information directly here:

@Davidewmd I've sent you a PM.

@rog943 there are times when forums and technical verbiage is not important, take care of yourself!!

I answer to this one separately in order to try to keep the main OP question central. Nevertheless, it is also pure logic this doesn't work. It could work by pure luck, or chance, but let's just think about this from a logical perspective (and I can assure you I've backed it up in practice*): - Any gauge or module can only poll at 18hz. This is the frequency at which the native panel SDK callback is calling you back basically. You can get higher frequency callbacks but this won't affect the other part, see right next. - SimConnect is not guaranteeing latency nor throughput. This means you can send packets an they will be stuck for a while until reaching the destination, where they'll arrive in bulk. So either ways, you will face the following situation with knobs (less so with on/off buttons but even then it glitches too): - in between the time you've polled the input last, and the time you're polling the input next - the knob has been turned N times and therefore the "software converting knob physical movement into software events" is writing N consecutive times the same LVAR with the value "1" (for CW rotation for example and "-1" for CCW). - now it is the gauge turn to read the LVAR and it only sees 1 x "1" or 1 x "-1", not N x "1" nor N x "-1" - Should you take a more "clever" path and do RMW to the LVAR (Read Modify Write ala ++ or --), then you're still not conveying the actual knob actions because turning twice CW followed by twice CCW would end up in 0. However turning twice CW and twice CCW is not the same as not turning at all for the device. Believe me, there is a reason we're overriding the native event system. It is not just for convenience and for integration, it is primarily because it is an event system triggering ala signal/slot, with a FIFO queue to ensure no events are lost and all events are delivered in sequence. *this is also why the RXP GTN knob input is 100% reliable when using 3D cockpit knobs, compared to another GTN solution using LVARs... and this is all locally without even the additional burden of SimConnect.

@Sling I believe I fail to express myself correctly because it seems you didn't understand at all what I've said. Let me try to rephrase so that we can explore possible solutions. No need to be condescending, it will lead you nowhere here. Rather, just scroll this page up: Can't be more clear than that... The OP want's to send two different sets of flight simulator commands depending on a "context" so that it can be done with a single knobster. This is irrelevant to anything gauge or simulator specific but just pure logic: if you have 1 emitter and 2 receivers, you have to tell which receiver the emitter is sending commands to. Therefore, taking the COM1/NAV1 and COM2/NAV2 example, how do you presently configure everything so that: 1) A single Knobster (1 emitter) can control both COM1/NAV1 and COM2/NAV2 when needed (2 receivers - not radio receivers but command receivers). 2) The user can switch which commands set to use at any given point in time, in order to send the corresponding commands to the corresponding COM/NAV set from the single Knobster. Once you got the answer to this, it won't be any different regardless of the gauge, meaning it won't be different with the GTN either...

@Sling Hi and thank you for trying to help! This replicates the exact use case the OP is trying to achieve but in using the COM/NAV radios only instead of the RXP GTN: - The OP wants to find a way to control 2 different sets of GTN radios with a single Knobster. - Each one in its own window. - The Knobster commands should be rerouted to one or the other based on which window is the active one. - The active window is the one he'd click into with the mouse/finger first to activate. And this is not AM business either anyhow: the Knobster ls just supposed to send "knob turning events" and that's all. It is up to the receiver of these commands to deal with them logically and contextually (i.e changing a frequency, moving a cursor etc...) Which is not the solution at all for very simple reasons: you can only poll such variables and therefore it is prone to miss successive events in a row... - Gauge polls LVAR and it is empty -> nothing to do. - Turn the knob and write LVAR - Turn the knob again and write LVAR - Gauge polls LVAR and there is 1 event only obviously, the last written one... You might want to re-read our User's Manual therefore...

@Dieter K. it will be hard to help you without even knowing which simulator you're having an issue with. Would you mind detailing this?

Thank you for the feedback Roger! It looks like they didn't read the RXP User's Manual, because the keyboard shortcut option is definitely supported in our products, but the preferred method is using the stock P3D GPS commands (see RXP GTN User's Manual p20). Regardless, maybe you could find a way in asking Air Manager: 1. Take the P3D Carenado Commander 114 2. Insert the following bold text in the panel\panel.cfg file: ... [Window Titles] Window00=GPS Window01=Manual Window02=Toggle_Control Window03=INFO Window04=COM1NAV1 Window05=COM2NAV2 //-------------------------------------------------------- [Window04] Background_color=0,0,0 window_size_ratio=1.000 visible=1 ident=15751 window_size= 0.200, 0.200 window_pos= 0.015, 0.600 gauge01=RadioC114x64!RadioCom1Nav1_1, 0,0,100,100 [Window05] Background_color=0,0,0 window_size_ratio=1.000 visible=1 ident=15752 window_size= 0.200, 0.20 window_pos= 0.015, 0.800 gauge02=RadioC114x64!RadioCom2Nav2, 0,0,100,100 //-------------------------------------------------------- [Window00] file=gps_295_background.bmp ... 3. How would you configure your hardware/software so that a single Knobster can control the COM1/NAV1 radios when you click/activate the Window #4, and the same Knobster would control the COM2/NAV2 radios when you click/activate the Window #5 instead. If you find a solution for this, you'll most likely get the solution for the GTN, because it is exactly the same use case: making the Knobster sending different commands to the simulator depending on which simulator window is active...

Hi David, until we know what is the root issue on your system we can't give any solution obviously. This doesn't mean there isn't any though, and this is why I'm guiding you to provide the feedback needed to assess the situation on your system first. When and if you feel ready to continue, please let me know.

just a quick note to let you know I've sent you all a PM with directions to test a new build!

Thank you for the additional information. Do you also have the detailed information about the CTD? If not, you might get a chance to retrieve it using this tool: https://www.nirsoft.net/utils/app_crash_view.html This might give additional details about what module more specifically is causing a problem.

Not the first time they are making some VR users wondering though:

The suggestion to test with the Mooney was to indeed test the Mooney equipped with the GTN. Can you please add the GTN to the default Mooney and try again?

The log files aren't showing anything peculiar except you're running P3D as-admin. What about the Mooney? What about just running P3D as a normal user?