Why a slow motion movir - speed of increments in course selector (PMDG 737 NGX)

[EPICfan 5]

Hi folks,

In short: Why does the value of the course selector increase at glacial speed (maximum changes of three degrees per second) with button pulses? How can you build a realistic MCP when the values change like in a slow motion movie?

 

Long: I am building a generic cockpit that can be used for a variety of aircraft. My hardware is the EPIC card. This hardware writes values directly to FSUIPC offsets. Let's take the course selector knob - if you change the course, a new value will first be created inside EPIC and then sent to FSX. As everything happens in EPIC, the impact on FSX is almost nil, and you can change course, heading, altitude very quickly. As I have programmed my scripts in a way that makes them "sense" whether knobs are turned quickly, I can do a 180° change with six notches of a turnable knob.

 

Now, all this does not work with PMDG, as PMDG does not have writeable offsets, if I have understood correctly. So instead of generating values, I have programmed my turnable knobs to send a joystick button pulse with every notch of turn.

 

With this, I need one notch of turn for every single degree of increment. In other words, I have to turn my 12-notch knob 180 notches i.e. 15 full turns to generate a 180° course change. This is not realistic.

 

So I have adapted my script in a way that EPIC still senses if the knobs are turned quickly. And if they are, it sends 10 button pulses within 0.2 seconds. With only FSUIPC, this leads to a 10° course change, but the 10 degrees take 3 seconds to change, like a slow motion movie.

 

With LINDA, this is the same only that sometimes it creates mayhem, and the course continues to change incessantly even if you close LINDA.

 

=> Can you help me find a way that button pulses are processed more quickly?

 

Best,

Holger

[ScotFlieger 280]

Hi Holger

 

Thank you for your detailed question. Sorry for the delay in answering but it need some study to answer you points. I think it would be best to describe how LINDA works and interfaces with USB HID devices. I assume you are talking about this EPIC USB card.

 

LINDA is designed to work VRInsight MCP Combo panels and joystick-type HID devices. The joysticks provide an on/off (press/release) notification via FSUIPC4 in a queue. The queue is processed at 20Hz and button presses are used to call a function written in LUA to carry out a generic action or one specific to the aircraft loaded. LUA is an interpreted programming language and therefore slow by today's standards. The MCP Combo panels are handled within the core linda.exe code.

LINDA is not suitable for rapid changing button presses such as those you describe coming from rotary encoders. These are best handled by FSUIPC4 and specific code.

 

LINDA is event and timer driven so it can be used to regularly read FSUIPC offsets and call functions to act on this data. Each aircraft module includes a Timer() function called at 1Hz which is adequate for most update processes. However, user inputs from knobs have to be handled 'immediately' and the display updated straight away. There is a higher rate 10Hz timer in the system module events.lua in hidPoll() function. This code can be modified to call your own functions like those used to update the Saitek panels.  However, modifying event.lua is done at your own risk as this system file is overwritten/updated with each install/upgrade of LINDA.

 

Aircraft specific modules have been provided using the SDKs supplied by the developer to take the button presses and provide the required input to the aircraft simulator via the SDK offsets or Lvars. PDMG aircraft are unique with their interface and study of the LINDA module will guide you on how to write values (like CRS) to the simulation. PDMG and other designer do not always stick with the original Microsoft FSX interface and offsets. One option is to use reserved FSUIPC offsets (like from 0x3210) to stored the EPIC USB output values and then use your LINDA LUA functions (in user.lua or lib:user.lua) to read these values as before and then interface these with the simulator. See the FSUIPC Documents/ FSUIPC4 Offsets PDF in the Modules folder.

 

Your last point is caused by the fact that there are 2 parts to LINDA - the GUI and the LUA. When you close the GUI (linda.exe) the LUA continues to run and if there is a long queue of commands it will continue to process them. The LINDA LUA will load when ever the Flt Sim is started but will not start receiving commands until the GUI is started.

 

I hope this helps you with your project.

[EPICfan 5]

Hi Scot,

Thank you very much for this comprehensive explanation. I see much clearer now. 20 Hz processing should be more than enough. My apologies if I have sounded as if I was criticizing LINDA for lack of speed. What I found slow was PMDG. It also seems to me that the number of inputs that PMDG can digest is limited, so it might be a good idead to have LINDA in between as a buffer.

 

I will definitely look into the option of using the reserved offsets and processing them through LINDA.

 

And yes, you are referring to the correct EPIC card. If we can solve this, we might finally have found a way to use EPIC hardware with PMDG products.

 

I will keep you posted,

Holger

[ScotFlieger 280]

Hi Holger

 

I am pleased that we have managed to clear up a few points.

 

Can I ask you to confirm whether the EPIC USB card reports a serial number in Setup Joysticks? Without this LINDA will not be able to distinguish because multiple cards of this type.

[EPICfan 5]

I am away from my setup, but I only have one EPIC Card which shows up as three different joysticks (EPIC 0 thru 2). So I guess there is no risk of "confusion". Will check in a few hours.

 

Best,

Holger