Using GTN750 Units 1 and 2 with a Air Manger DIY Knobster

[rog943 14]

I hope someone can help me with this problem. FSX Steam and Carenado Aztec.
I have just finished making a DIY Knobster which works fine with most of my AM panels.
However in one situation I like to use two popouts from my Reality XP GTN750 - Unit 1 to control Nav1 and Unit 2 for Nav2 which works well with the mouse.
I have replicated my problem by creating one new panel and inserted two AM GTN750 Overlays for the GTNs.
The popouts are dragged onto the panel and lined up beneath the overlays. All looks good.
If I mouse click on unit 1 all is well, the button lights up  and the nav/com frequencies change and I can click to swap. If I then mouse click on unit 2 the button lights up but the knobster still operates unit 1. I can of course change unit 2 settings with the mouse but that somewhat negates the point of the knobster.
My usual flight situation here is with two separate (non touch) screens and two separate panels - same problem. On the unit 2 panel I can set the OBS on the VOR2 instrument with the knobster but not the 750 frequency settings.
Am I trying to do something I can't do? Or, hopefully, am I doing something wrong or not doing something I should?   I asked first at Air Manager who say it is a Reality XP issue.  (I notice that the Overlay for X-plane can have a number allocated to it.)
Thanks in anticipation.

[RXP 2,338]

Hi,

If I understand correctly, you'd like a single hardware controller to selectively control one or the other GTN?

If this is so, the problems boils down to how would you tell the knobster that at one point in time it'd send commands for COM1/NAV1 for example, and at another point in time it would be for COM2/NAV2. This in itself is not a RXP related question but a more general one:

- how to bind 1 hardware device onto 2 different sets of commands dynamically.

Posing the question leads to the answer: is there any way you can do this with the Knobster regardless of RXP?

If so, what is the "trigger" or the "state" which determines which COM/NAV set the Knobster is controlling at any given time?

Once you get a "trigger" or a "state" to look for, it will become much easier to also use this state to just bind GTN1 or GTN2 controls dynamically as well.

[rog943 14]

Hi Jean-Luc,

How lyrical.

I would have thought that the answer was that when Unit 1 knows it is Unit 1 and I know that when I mouse click on Unit 1's button it knows what I want from it.  The trigger is when I press the one button or the other.

Following that through I move physically to the button on Unit 2 etc etc.

Obviously my ignorance of how all this works leaves me without a solution - or a workaround - to my problem.  Could it be that you are saying that the only way to do this is to have another knobster?  Can people who have X-plane do this?  If they can - lucky them.

Regards,

Roger

[rog943 14]

Just to follow up - I hope, looking at my post you will not take offence at my use of the word lyrical.  The way you took me through it all was almost poetic.

Just to underline my confusion - at any moment in time units 1 and 2 manage to hold different frequencies from each other so they do appear to have independence from the 'mother' unit' in the 3d cockpit.  That I find amazing so it's a bit disappointing to find this stumbling block with the knobster.

[RXP 2,338]

Don't worry, I take no offense except that I might have failed to express myself clearly enough, therefore I'll try more!

At least I believe I perfectly understand what you're trying to achieve, so let's try to find a way.

You might want to think of this not from a window manager standpoint, i.e. the "active" window, or the "focus" window would be the one receiving inputs. In effect, each device is standalone and has even no knowledge it is in a window (well technically it does otherwise it wouldn't draw, but it is rendering output surface agnostic in design and can draw on 3D panel, on popup window, etc...). Or said otherwise, the window state (focus) is not a RXP gauge state itself (and actually this state is not accessible via the SDK, it is something solely handled and managed by the simulator itself).

Instead, each device can be configured to receive commands from various inputs (keyboard, hardware, other gauges and modules), and each is individually binding to its own set of commands. Which means the selection/triage of what commands goes from your hardware to the simulated device must reside at the hardware level, not the simulated device level (i.e. at the source, not the destination).

In the particular case of the frequencies, since the GTN or the GNS V2 are synchronizing bidirectionally with the simulator, if you flip flop the simulator COM2 for example, the RXP GTN or GNS V2 device configured with COM2/NAV2 will automatically sync the change as well on its own display. So in this particular case, if you can manage to dynamically configure the Knobster to send COM1 flip flop or COM2 flip flop commands at will, then it will work as expected too with the RXP devices.

Now having said this, if you find the way to do this with the knobster, then it will be as-easy to extend this concept of dynamically changing the set of commands for more commands, including those pertaining to the rest of the GTN and GNS V2 controls.

So, maybe the easiest would be for the company making the Knobster to support dynamic banks of commands at runtime to get started. If they already do, then what would remain is finding a way to swap banks based on an external signal, but in this case, if it is about detecting which window is active because you've clicked on it, it is out-of-gauge jurisdiction and solely in the hands of the simulator. At this stage, wouldn't it just be easier to use 2 Knobsters instead, and if not for the GTN and/or the GNS V2, you can still use both for many different things (OBS, CRS, autopilot altitude input, vs input, etc...).

Hope this helps!

 

[rog943 14]

Wow!  I'll spend time trying to absorb all that.

As always I do appreciate your support.  Great product.  I'll probably run this past the AM guys just to see what reaction I get.

All the best,

Roger

[rog943 14]

Hi Jean-Luc

I have been in touch with support at Air Manager and even sent them a video clip of the problem I raised with you.  Does their reply - suggesting changes to the Reality XP kit - make it likely that changes would make what I am trying to do possible?

From Sling -  'I’ve watched the video and indeed you have the issue I was expecting. The only way to truly make this work with FSX is for RXP to update their product to use LVAR’s for the Nav/com2 controls. All they currently offer is keyboard mappings. If they are not interested in doing this you are stuck. The GTN overlay could be modified to solely control the frequency selection but then would not function as as an FMS knob when on another page that needs control via the FMS knob. Equally you may be able to fix it to the FMS Knob but the frequency control will not be possible.

A set of RXP implemented LVAR’s would just be control of the basic knob just like GTN 1 works so it would know where to direct the knob change to based on the currently selected page/field.'

Thanks,

Roger
 

[RXP 2,338]

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...

Edited February 16, 2022 by RXP

[rog943 14]

Thanks Jean-Luc.

I'll go back and see what they say in reply to your comment.  I'll be in touch.

Roger

[Sling 16]

Hi Jean-Luc,

I have been trying to help Roger with his issue. I understand how Air Manager and the knobster work and can therefore probably answer any questions about this rather than Roger go backwards and forwards. The RXP manual has indeed been read and understood. If you read my comment you will see I say that all you seem to offer is keyboard commands. Unfortunately AM uses sim connect as it’s means of communication. So AM needs a sim event or writable var to send the knob input to. In the case of GTN 1 this is done by using the built-in sim events that RXP support. However for GTN 2 there is no equivalent. Yes the individual events for everything the knob controls could be used if they are all available for a second unit but as I also said in one of my replies this would also need a variable from RXP that provides the data for what function to control based on the currently displayed page. AM would have no way of knowing if it needed to control frequency, FMS or whatever without this. I think this has come about because FSX only has one GPS and you have quite rightly added an option to use its default events for the GTN. However that does not support control of a second GTN as far as I can tell. This is why I suggested that RXP need to include some custom writeable LVAR’s specifically for the control of a second GTN’s bezel controls. If you have another way to achieve this then that is what Roger seeks. 
I’m not sure what the panel.cfg edit that you posted achieves but if it changes the default event focus between. GTN1 and GTN2 then the AM instrument can remain as is but the user would need to make sure the window focus changes.before trying to send any events. I guess they would do this by clicking/touching the display area before using any bezel controls.

Edited February 18, 2022 by Sling

[RXP 2,338]

@Sling Hi and thank you for trying to help!

7 hours ago, Sling said:

I’m not sure what the panel.cfg edit that you posted achieves

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.

 

7 hours ago, Sling said:

AM would have no way of knowing if it needed to control frequency, FMS or whatever without this.

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...)

 

7 hours ago, Sling said:

RXP need to include some custom writeable LVAR’s

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...
 

7 hours ago, Sling said:

In the case of GTN 1 this is done by using the built-in sim events that RXP support. However for GTN 2 there is no equivalent.

You might want to re-read our User's Manual therefore...

Edited February 18, 2022 by RXP

[Sling 16]

2 hours ago, RXP said:

You might want to re-read our User's Manual therefore...

Rather than just keep repeating this belief that the user manual has not been read it would be more useful if you directed us to whatever section you believe details the sim events for a second GTN. 

Actually the OP does not want to just control 2 sets of radios because this can and is already being done. For this he certainly would not of needed to ask a question in this forum. Let’s be clear, His specific issue relates to doing it with dual RXP GTN’s. 

So it seems you are suggesting the RXP solution to control a second GTN is the rather undesirable work around of having to touch the window first before trying to control it and before being able to do that every aircraft you want to use this setup with will need a modification to one of the aircraft files. Surely RXP can do better than that.

The suggestion of using LVAR’s was based on previous success with the use of LVAR’s to send data to the sim for such tasks as controlling sim avionics so indeed it can work well. Perhaps not for your unit.

the Knobster ls just supposed to send "knob turning events" There is no supposed to when it comes to knobster. It does whatever you tell it to. For your own education knobster doesn’t send anything directly to a sim. It simply mimics the AM instrument functionality in hardware, no more no less. Therefore using it is not at all relevant to this issue because the soft control behaves the same without even using the optional knobster.

 

[RXP 2,338]

@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.

2 hours ago, Sling said:

Rather than just keep repeating this belief that the user manual has not been read it would be more useful if you directed us to whatever section you believe details the sim events for a second GTN. 

No need to be condescending, it will lead you nowhere here. Rather, just scroll this page up:

On 2/16/2022 at 11:38 AM, RXP said:

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).

Can't be more clear than that...

 

2 hours ago, Sling said:

Actually the OP does not want to just control 2 sets of radios because this can and is already being done. For this he certainly would not of needed to ask a question in this forum. Let’s be clear, His specific issue relates to doing it with dual RXP GTN’s. 

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...

 

Edited February 18, 2022 by RXP
reworded for clarity

[RXP 2,338]

2 hours ago, Sling said:

The suggestion of using LVAR’s was based on previous success with the use of LVAR’s to send data to the sim for such tasks as controlling sim avionics so indeed it can work well. Perhaps not for your unit.

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.

Edited February 18, 2022 by RXP
edited for clarity

[rog943 14]

Hi guys,

I am watching this with interest.  Somewhat distracted by having just caught Covid.   I'll catch up shortly.

Roger