Software

TQ Software controller

January 18, 2014

My TQ software controller  is a visual .Net application that I wrote myself. It allows monitoring all necessary readings from Pokeys and FSUIPC (besides direct TQ control functions). It  is also used as  TQ test application, allowing easy parameters and logic  refining.


Application is also used for potentiometers calibration.  Overall, all TQ functionality is a combination of my custom .Net application that uses Pokeys, Phidgets and  FSUIPC  DLL libraries ProSim737 communicates with controller through Pokeys card.


Here is what was initial interface version (the look changed frequently  :))




Here is a latest interface version:


It supports all the TQ functions, including:

    Manual thrust lever control.
    Autothrottle functions.
    Flaps lever function.
    Flaps indicators.
    Autorelease for parking brake lever.
    Speedbrake functions with automatic deployment on rejected takeoff (when reverse is applied) and landing with or without armed speedbrake (no reverse required).
    All TQ buttons input.

Boxes on the left represent the analog inputs from TQ pots. The necessary number of inputs is defined in configuration file and the controls are dynamically created. So, if tomorrow I want to add another analog input, I just need to change the app.config file to tell which Pokeys analog pin is used for it - and automatically will have all monitoring info on screen in additional box.

Application was designed to support both USB and Ethernet versions of Pokeys card. (Note:  when I tested it with Pokeys Ethernet card, I found strange glitches in software and for now I just set testing Ethernet version aside and switched back to Pokeys 56 USB).

The box in the middle represents the actual TQ and the sliders move when TQ  levers move.

The box on the right represents autothrottle  functions.  Autothrottle input  is switchable from FSX input to input from sliders (trackbars) in autothrottle box. That mode is typically used for testing or demonstration of levers movement. The levers can be activated from it separately or synced to move together. The advantage is that I do not have to run the actual flight in FSX in order to test the logic or algorithm changes. In fact, the application autothrottle logic just reads the position of autothrottle sliders to command the lever motors.

When in FSX input mode, the  FSUIPC throttle read values just assigned to the slider position value. All necessary FSX offset values can be monitored in screen. For the throttle levers the application reads from FSUIPC offsets 088C, 0924 and writes to offsets 089A, 0932.

Here is the video of working TQ:





 

Electronic cards of choice are:

    Pokeys 56 (57)
    Phidgets 1064 2-motors card for throttle levers (DC motors)
    Phidgets 1065 1-motors card for trim wheel (DC motor)
    Phidgets 1061 8-servo card for speedbrake and trim indicator.
    Electronic relay for parking brake release.

All these cards have DLL libraries for .Net and  sample .Net projects are availabe.

All TQ analog and digital inputs go to Pokeys card.

I found one limitation due to using Phidgets and Prosim software. Apparently only one client application can work with same Phidgets card at a time. Meaning, it’s either Prosim or my TQ application (or any other application working with Phidgets card - for example one of Phidgets test applications).

Contrary to this,  Pokeys.dll and FSUIPC.dll allow simultaneous access from multiple applications.

So, if you enabled Phidgets support in Prosim and start Prosim, then  Prosim  takes control over all Phidgets cards connected. If my TQ application is started after Prosim - its functions controlled by Phidgets cards will not work because Prosim already grabbed the control over them. And vice versa.

If my TQ application is started first, it will work properly.  Prosim, being started after it will just hang trying to get a hold on Phidgets cards.

Using Phidgets test applications I figured that generally there is a possibility to use different client applications with different Phidgets cards.

For example, Phidgets  1-motor card and 2-motor cards  are connected. 
You start Phidgets motor card test application. It will get a hold on first card it sees. Then you can start the same test application second time and it will connect to the second card. Start third copy of test application and it will not work since all cards are already in use. Phidgets supports opening particular cards by specified card ID and I use this in my TQ application. So, the issue possibly could be resolved in Prosim software. Currently Prosim just tries to take over all connected Phidgets cards, if Phidgets support is enabled.

 It could be possible to let Prosim setup to read the connected Phidgets cards, display them in the setup page and allow user to choose which Phidgets cards should be used with Prosim.  My TQ application works with individual Prosim cards, identified by card ID that is stored in app.config file, so it will not try to open any other cards. But currently Prosim has no way to specify which Phidgets card is used by Prosim and which by another application.

All this means that currently one who wants to use my  TQ application can use Phidgets cards only for TQ application needs. If you want to use some other Phidgets card (not related to TQ) with Prosim and enable Phidgets support in Prosim - it will not work, since Prosim tries to get hold on all connected Phidgets cards at once.

I tested Prosim-Phidgets connection with Speedbrake functionality and it controlled Phidgets 8-servo card  fine. However, because of this cards access limitation, I had to program Flaps and Speedbrake functionality logic  into my application myself, instead of leaving that to Prosim.

My application code could be refactored and enhanced more, of course, but one finally needs to stop changing at some point. :) .  Therefore it is now in the state that allows use in the simulator. Further enhancements are planned, but put on hold, until I complete some other vital parts, overhead for example.

Since analog pots always have also some "noise" and readings are fluctuating, I use so called "rolling average" value (calculated from last 10 readings) for pot position reading.  This is the  "Stabilized value" in screen above.  Smoothing gets the reading value fluctuations down to +/- 1 range.

The application reading cycle is 100 milliseconds ( it is a configurable parameter, but 100 ms appears to be the most reasonable value).

In addition to  rolling average   there is another level of smoothing  for throttle levers. The motors will react only if the lever movement reading goes beyond a defined range.

Simulator startup procedures.

 I use a combination of methods to start the simulator computers and all sim software.


 I use  WakeMeOnLan  utility  to start  the avionics computers.They all are configured to enable wake-up on LAN functionality. The utility allows to select all desired computers and start them up  at once.

When the computers started, its time to start all simulator applications.

On the main computer I start the batch file that starts Prosim737 and P3D.

FSUIPC.INI file  is configured to start Prosim MCP, Prosim Audio and my TQ control application.

The rest of avionics computers have the batch files in Startup folder. So,  Captain's Prosim Display,  Captain's Prosim CDU and F/O Prosim Display and Prosim Audio modules automatically start with their notebooks. All Prosim modules that are not on main flight  computer are set to allow the remote shutdown.

For shutting down the avionics notebooks I can use either Prosim Instructor Station, or Input Director application. Main computer currently is shut down manually. Since I still do a lot of changes, there is no point to further automate startup/shutdown at this point.

Textures, Shaders, Weather,  etc. 

January 11, 2018

There is quite a number of packages that you can use for enhancing your simulator experience.

They represent three main functionality categories. That includes weather engines, texture packages, shader packages. Every new version of such software has something to offer that you are tempted to try. They do not 100% overlap in functionality. So, how all they play with each other?

Let's consider a few most common packages that provide these features. Note, that it's just my view and my understanding on this subject, based on my experience. It's not  the ultimate truth and I might be mistaken about how some options may work.

In no particular significance order:  (since some people swear on Rex textures, other love ASCA or Envtex or yet something else...)


- Rex Texture Direct + Soft Clouds
- Rex Sky Force
- AS2016 (or AS4 for P3Dv4) + ASCA
- Envdir, which is a common interface to Envtex + Envshade (they also could be used separately)
- PTA

First let's look at what they do:

1. Rex Texture Direct + Soft Clouds
Essentially it is a textures package which also includes a weather engine.

Textures include the following groups:
Sky
Clouds
Water
Sun/Moon
Lightnings/special effects
Airport textures
Also there are rain/thunder sounds included.

2. Rex Sky Force

This is the newest package that combines the weather engine and sky/clouds package that has lots in common with Rex Texture Direct + Soft Clouds while it implements new cloud structures and the way to dynamically change them along the flight.

Sky
Clouds
Water
Sun/Moon
Lightnings/special effects
Note: NO Airport textures!

3. AS2016/AS4 is a weather engine and ASCA is a Sky/Clouds texture package that can also dynamically apply selected textures sets while you are flying.

4. Envdir. It is a common interface for Envtex and Envshade.

-Envtex includes:

Sky
Clouds
Water
Grass
Sun/Moon
Lightnings/special effects
Two sets of Airport textures, bot not with that many separate options setup as in Rex TD.


-Envshade: This is a shaders package, but it does not have extensive set of options like PTA.


5. PTA - Extensive shader package with many options. To make life easier people use PTA presets - which are sets of selected PTA options for different scenery situations.

Sure, winter Norway sky preset will be different from summer Caribbean sky preset.
Of course, any option in selected shaders preset may be changed to your liking later.

As you can see the above packages do not 100% overlap each other in functionality.

Besides the default weather/texture/shaders functionality, that your sim provides, you may want something better. You have a choice of better (or more comprehensive) functionality from these packages. How you can take advantage of many or all of them?


So:- Rex Texture Direct + Soft Clouds and Rex Sky Force are more or less similar to AS2016/AS4 + ASCA in overall functionality.They include weather engine and texture packages.

- Envdir (Envtex + Envshade) contains textures and shaders and ASCA has ability to integrate and work with selected Envtex sky textures.

- PTA works only with shaders.

A good thing for weather engine choice - you can use any of them or do not use one and use weather presets in simulator. I often use weather presets instead of live weather (mostly because if one want to make a nice scenic movie from the sim - then the live weather probably is the last thing you would use. :) )

From what I see, the Rex TD is mostly considered as comprehensive and very good texture package, while AS2016/AS4 is the live weather engine of choice for lots of people. Weather engine currently supplied with Rex Sky Force is questionable for now, since it has unvanted visual effects on scheduled weather updates (injections).

Here is a couple of scenarios:  (Let's set shaders aside for now.)

1.  You can use AS2016/AS4 as your weather engine and load the desired sky/cloud/sea textures from REX TD. In this case the loaded sky/water textures will be used in any area where you fly.

2.  You can use AS2016/AS4 as your weather engine and load the desired sky/cloud textures from ASCA. If you use  ASCA, you can optionally use its "Dynamic" scenarios that will be loading the appropriate textures along the way. ASCA can use its own sky/cloud textures, integrate with Envtex sky textures or just use the currently loaded textures no matter where they are coming from.


OK, now what happens if you want :

-airport textures, lightning, water from Rex TD,
-sky textures from Envtex, 
-clouds and cloud structures from Sky Force
-Global Dynamic sky/cloud texture changing in ASCA
?

How to ensure you are using the desired textures that are spread between different packages? Considering that Rex TD, Envtex and ASCA have their own sky and clouds sets?


Go to ASCA  config and set the checkboxes checked only for Cloud Structures and Sky Colors:

You may previously have already loaded some textures from ASCA (or some other package),  if you used them before already.

Optional thing to do is to restore your default textures in sim. That can be done through Rex TD - when it installs it makes a backup copy of default sim textures (meaning the textures that were installed in sim before Rex installation). Envdir also makes the textures backup.

Create the theme in Rex TD and choose the desired airport textures, lightning and water options:

Next, go to Rex TD setup and leave checked only the corresponding item  types that you want to load when you click on Install Theme in Rex TD:

As you can see above, only water, runway/taxiway, airports and sound effects are coming from Rex TD.

Run Rex Sky Force and similarly - select desired cloud structures/textures/options and save them to the theme.

Like in Rex TD before, go to Rex Sky Force setup and leave checked only the corresponding  cloud item types that you want to load. Install the theme into sim:


As you can see above, only cloud structures/textures and sun/moon textures will be installed from Sky Force.

Go to Envdir, choose sky textures you want and again, like before - uncheck everything but Sky and Grass checkboxes:


As you can see above, only Sky, Grass and shaders are coming from Envdir. Envdir is set to integrate with ASCA.  Note, that ASCA Integration option in Envdir is set to ENVTEX textures only.  This is up to you - you can set it to use Envtex + ASCA sky textures.

Now Install selected  from Envdir into simulator (use green button).

Install your prepared themes from Rex TD and Rex Sky Force.

If you did not make any mistakes in all those install settings, then:

-your sky and grass textures in sim are coming from Envtex,
-cloud structures/textures, sun/moon textures are coming from Rex Sky Force,
-airport textures, lightning, water coming from Rex TD.


And ASCA just uses:

-sky textures from Envtex
-dynamically loads the clouds that are currently installed in sim (we got them from Rex Sky Force)

Similarly, if you do not use Sky Force and want to use Rex Soft Clouds with ASCA, then just load desired clouds from Rex at the corresponding step. Better to load them in the last order, to ensure that loaded textures in the sim are from desired package.

Hope you got an idea how you can manipulate those packages and have a combination of their textures/options in your sim.

Remember that many same texture options are presented in all packages, so if you do not set properly what texture types  to load from each of them, then the texture loaded from the last used package last will be used in sim.

Shaders

Now, for the shaders effects, the easiest option might be to check "Load Shaders" in Envdir interface.

Here is how sunset and sunrise look like with shaders from Envshade.







 


 







If you have PTA, then instead of using shaders from Envshade you could create or use some preset and load that from PTA. It is always a good idea to keep the copy of the default shaders and restore them into sim before playing with the new shaders/presets.

Rex Sky Force has the option that integrates with PTA. I did not try to use it yet.