VisualPSX Suite build 5427 uploaded

[Garry Richards]

Hi Gerd and Markus,

All I can think of is that the traffic is out of range vertically. In case you haven't considered this the ranges for traffic to be shown ton the ND for the Above/Normal/Below switch positions are:

A +7000 and -2700 ft.
N +2700 and -2700 ft.
B +2700 and -7000 ft.

Cheers,

[Garry Richards]

Hi Jean-Philippe,

I think this could have to do with either SimConnect or Visual C++ or the .net framework as mentioned on page 2 of the manual. But I am sure you will have installed them as per the instructions.

So that leaves your Windows version and maybe something missing in support for 32 bit applications if you are using a 64 bit system. This shouldn't be a problem, They run fine on my 64 bit computer.

I'm afraid I'm grasping at straws here. Sorry I can't be more helpful. I hope somebody finds the solution.

Cheers,

[Markus Vitzethum]

Hi Garry,

> All I can think of is that the traffic is out of range vertically. In case
> you haven't considered this the ranges for traffic

negative on both items, I'm sorry.

To be precise, I was watching VATSIM landing traffic (ILS25C) at EDDF while sitting on the ground at EDDF with APU running, TCAS in TA/RA, altitude selection to ABOVE, TFC switched ON on the ND.

Since it was landing traffic it was within the TCAS vertical range. And all VATSIM traffic was correctly shown in the (debug) TrafficPSX list of aircraft at altitude +5000' or less.

I was expecting to see the landing traffic on the ND; my understanding of the inner workings of TCAS (from programming a TCAS add-on for PS1.3 many years ago) is such that an aircraft on the ground can indeed see and display airborne TCAS targets while on the ground.

The observation was that the traffic (I see in FSX and the TrafficPSX list) is not visible on the PSX ND.

Now I wonder ... is there a way to read out the PSX keys (by a third party program or by TrafficPSX) to check out the PSX variables after PSX has written the TCAS data into PSX.
(If I'm not wong - not at home right now - I can point a web browser to the PSX server...  to read the keys.) The idea is to check whether the TCAS data is actually available in PSX.

Markus

[United744]

TCAS doesn't care for ground/air state of the aircraft, except for switching from TA RA to TA ONLY (and then, this switch occurs below 1000 ft RA).

[GerdD]

All I can think of is that the traffic is out of range vertically.

Hi Garry,
that cannot be, because I had altitudes within the -2700/+2700 range
in the test Version and collision alert in FSCommander with previous Version.
http://www.hoppie.nl/forum/var/GD_Traffic_Traffic.jpg

In my opinion the Problem must be something basic cause
I never saw one aircraft on PSX-ND after TrafficPSX has been connected.

Regards
Gerd

[GerdD]

Garry,
have made another test with your Debug-TrafficPSX.
Screenshot attached. I think You agree, that one aircraft
should have been displayed, idependent of the switch setting.
PSX setting was on "Externally controlled".

http://www.hoppie.nl/forum/var/GD_Traffic.jpg

Regards
Gerd

[Britjet]

I have been monitoring VISUALPSX traffic vs what is actually there by using AIVLASOFT electronic flight bag. I am using MyTraffic3D, which seems to also include the FSX default traffic.

In the cruise it works OK, with a range of about 50nm. I can close in and formate on the traffic and it still shows, down to zero range..

Near an airport, however, and therefore at lower altitude..nothing. I can follow traffic round the pattern and onto final and they show only intermittently. Is this an issue with the amount of traffic available?

All VATSIM traffic shows without problems.

Rgds,

Brit.

[Markus Vitzethum]

Hi Garry,

I think I found something important: decimal seperator.

Okay, first time I looked up the network documentation (back to add-on programming for me, like in good 'ole PS1 days?   ). I quickly discovered that I have to follow network variable Qs450.

Okay ... when running "pure" PSX (no add-ons), but with TCAS set to a "high conflict random loop" I get - as expect - frequent changes to Qs450. Using a telnet client I am following these changes and Qs450 look like this:

Qs450=0.8716363183192828;0.15016287801403205;8633;14270;

When I fire up TrafficPSX (still debug build 5428 ), I sure see Qs450 changing but it looks different:

Qs450=0,899816335840437;-0,0139523366801594;31590;23597;

--> important difference highlighted in red color: the decimal seperator is a comma and not a decimal point

Conclusion:
I am using a german Win7 system where the system default is "," (comma) as a decimal seperator. This is standard on many non-US/english windows systems. It looks like TrafficPSX is using the system default decimal separator and not the "." required by PSX. It also explains why it works on some systems (US/english settings) and not on others.

Solution:
make TrafficPSX robust to country-specific Windows settings of the decimal separator.
In most of my Delphi programs (especially those dealing with NavData text files), one of the first lines of code reads:

Code Select Expand

DecimalSeparator := '.';

to set the decimal separator country-independent. I am confident that there is similar setting or global variable (Delphi puts it in the SysUtils library) in your programming language.

Of course, this is helps for any floating point variable TrafficPSX is transmitting to PSX. Maybe this also explains other effects with TrafficPSX or VisualPSX. Possibly, you can cross-check whether any other items with both programs using floating point numbers and have reported issues here (e.g. weather).

Okay, hope this helps.

Markus

p.s.
I still like the 1-7 traffic list of the debug version of PSX. It clearly shows whether the traffic is correctly transferred from FSX to TrafficPSX. Any chance to keep that?  

[Markus Vitzethum]

Hi Garry,

update and cross-check.

I've just changed my country settings for the decimal separator from "," to "." - and TrafficPSX works just fine, that is, I see the traffic in PSX.  

(But I do not want to keep that because it has side-effects on just about every program.)

So the quick fix for those in need is: change the decimal separator to ".".
The permanent fix is a decimal-separator robust build of VisualPSX and TrafficPSX.

Markus

[Garry Richards]

Hi Markus,

Good sleuthing! Your previous asking about the output must have set my mind to work while I slept because I woke this morning with the same thought. I was intending to do the same test that you did but you have proved the cause already. Thanks! That saves me some work.

I routinely control the numerical formatting to allow for non-English systems but must have overlooked it in this case. I will release a fix later today.

Cheers,

[GerdD]

Heureka!

Markus, you got it.
Changed my decimal and traffic is fine.

Regards
Gerd

[JP59]

Hi Jean-Philippe,

I think this could have to do with either SimConnect or Visual C++ or the .net framework as mentioned on page 2 of the manual. But I am sure you will have installed them as per the instructions.

So that leaves your Windows version and maybe something missing in support for 32 bit applications if you are using a 64 bit system. This shouldn't be a problem, They run fine on my 64 bit computer.

I'm afraid I'm grasping at straws here. Sorry I can't be more helpful. I hope somebody finds the solution.

Cheers,

Thank you Garry. My fresh install included a complete VisualPSX installation by carefully following the manual, step by step.

[Garry Richards]

Hi traffic testers from lands where English does not reign supreme,

I had indeed overlooked the numerical format requirement to make the traffic data flow independent of the local language and it is now fixed. I also checked both TrafficPSX and VisualPSX for any other oversights and found a few. They involved integers so probably were being passed correctly anyway but for completion I standardised them too.

Here is the debug 2 version of TrafficPSX.

And here is the debug 2 version of VisualPSX.

These should work without you having to change your computer's numerical formatting rules.

Once again thanks to Markus for finding and confirming the cause.

Cheers,

[GerdD]

I had indeed overlooked the numerical format requirement....

Garry,
take it easy. You´re not the first one where this happen.
The most important thing is that due to the efforts of
You and Markus the problem has been identified.
Thanks for this.

Regards
Gerd

[Garry Richards]

Hi Gerd,

I am delighted that this problem has been solved, particularly because it didn't involve any logical error in my code and also because it prompted me to check all my apps for the same oversight.

Applications intended for an international audience have to be robust and should automatically display numbers in the user's local format while communicating with other apps in a standard format. It's a bit like using UTC  in aviation, converting to local time only when necessary. This exercise has enabled me to confirm that my software now complies fully with this requirement and so I feel very pleased.

As you have suggested, I will be taking it easy today. My wife has a lot of gardening planned for me!

Cheers,

[Britjet]

My country settings are UK based, with decimal points.
It's still not working for me, I'm afraid.
I am using the debug program and traffic appears on that, but not on TCAS.
Nice sleuthing, though....

:-(

Brit

[Hardy Heinlin]

Be sure to use the debug 2 version.


|-|

[Britjet]

Yes Hardy, I have just done that and moved things around on the network.
Now getting the aircraft consistently in the cruise.
Thanks!

Brit

[Markus Vitzethum]

Hi Garry,

thanks a lot for the debug2 version. This one works - as expected - fine for me.

Can I please repeat my request to keep the traffic list in TrafficPSX? One of the reasons is that I can easily correlate the TCAS targets to the respective callsigns on VATSIM. However, the main reason is that I have seen one or two occassions of TrafficPSX getting "stuck", that is, no longer updating VATSIM traffic data (for a specific aircraft [only 1 visible]).
(I cannot really name specific conditions but with the traffic list it is easy to identify such a condition and e.g. restart TrafficPSX.)

Thanks a lot,
  Markus

p.s.
Gardening season is mostly over here in Europe so the tasks by my wife are finished, but I understand that on the southern Hemisphere, summer hasn't even started yet.  

[Garry Richards]

Hi Markus,

Sorry, I missed your ps question. In answer, yes I will make the traffic identification display permanent and I will also activate the traffic display for traffic from PSX to FSX. Actually both of these have been there all along, but turned off. I used them for debugging when I was developing the original traffic flow algorithms.

I revised traffic handling in version 5.5 so stuck traffic shouldn't occur now, but I haven't tested it over a several hour period. I will assume it's fixed until I receive a report to the contrary.

Cheers,