LecLightning56

Further testing has indeed identified mono sound files which use sound cones in the external view (viewpoint=2) entries of the jet whine components of the custom sound sets which I have been using (you will find these in your customized, e.g. Turbine Sound Studios soundai.cfg files which you have to use for AI aircraft using UT2). If I convert these mono files to stereo, then the intolerable noise disappears. This seems to be a permanent fix. For reference if you are using TSS sound packages, the sound files concerned typically have names such as WhineAX, FanAX etc. for the external sounds associated with jet whine. If they are mono files (check using the Audacity freeware software), then convert them to stereo (again using Audacity) and you are done!
 
Happy plane-spotting with AI aircraft in the meantime!

At last some progress. It would appear that the problem all along has been the setting of null zones for the controller axes. In particular, it would appear that the setting of a null zone for the aileron axis is the main culprit. My yoke centralizes accurately in the roll axis, so upon removal of the null zone for the aileron axis I am now getting acceptable results in my 'test' conditions whereby the 'drift' is minimised to an acceptable level (with minimal control inputs and no aileron inputs whatsoever, the PMDG 777 now touches down approximately 5 feet to the left of the centreline, which is very much better). So, just to recap, this appears to have been a controller calibration problem associated with the setting of a null zone in the aileron axis which is largely to blame. There is no further need to disconnect the primary flight computers as previously reported. I shall now go away and experiment with non-FBW aircraft (outside the scope of this thread).
 
I wish that there was a more authoritative guide to best practice with controllers where the use of null zones and sensitivity is concerned with application to FBW and non-FBW aircraft, but perhaps it is left to the individual to determine for himself to adjust accordingly to achieve the best results.
 
I think that I can discount FSiPanel in terms of the weather settings since these have always been set in FSX after FSiPanel has positioned the aircraft for the landing.
 
Thank you all for your contributions and if anyone has anything further to add then please send in your comments as you see fit.
 
 
Paul Hermon

Thanks for your advice. All seems logical now that I have specified the navdata folder from Level-D and Vox is now identifying the SID correctly from the loaded flight plan. Thank you all for your comments and advice.

For whatever reason my experience has now changed and I am getting the same situation that you have described, which I would suppose to be normal.
 
So a temporary blip in performance for unexplained reasons, but back on track now.
 
Thank you all for sharing your experiences.

Problem solved. The CH Eclipse Yoke is plug and play and does not install drivers. If you install the CH Manager software for the product (as I did), Windows 7 does not recognize the yoke as a game controller. The net result of this is that VoxATC will not identify the yoke whatsoever.
 
The solution is simple: uninstall the CH Manager software and then the yoke is identified as a game controller and VoxATC will acknowledge its existence.
 
So case closed!