News:

Precision Simulator update 10.175 (29 May 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

RealTraffic 1.0 beta and updated Foreflight 2.0 beta

Started by Balt, Sun, 18 Jan 2015 15:39

kev32b

Hi,

Just a question does realtraffic sent traffic to fsx through visual psx/traffic or is there something else to be done for this to work

would be nice to see real traffic  in fsx

K



Balt

Hi

RealTraffic makes the traffic available for any plugin developers. There's at least one visual system addon that supports this feature, I'm not entirely sure which one as I haven't used this in a while, but I'll take a look later today when home.

Cheers

Balt

kev32b


kiek

Now even more possibilities for RealTraffic users, see this post about PSXseeconTraffic: http://aerowinx.com/board/index.php?topic=3351.0

Balt

Sounds great! I haven't been able to try this yet as I have no suitable Windows setup, but maybe in the new year I can repurpose an older Windows box and try it.

Cheers

Balt

kiek

Hi Balt,

After playing with PSXseeconTraffic for a while, I've noticed that the updates of traffic data in the ForeFlight stream occur EDIT 2 3 times after about 8.5 seconds and then 1 time after about 17 seconds. This is a repeating pattern. Why is this, why not at regular intervals?

And another question. How do I have to inpret the latitude and longitude in these data? A) As being the position at the time of receival or B) as a position in a fixed timeframe?
There is no time info in the data so at the moment I process the data according to A) but this gives irregularities in the movement of the aircraft, i.e. the "speed/movement" of cruizing aircaft changes between these intervals of about 8,5 seconds.

Best regards,
Nico

Balt

Hi Nico,

The data is valid at the time it was received. There indeed are no timestamps, and I make no extrapolation of the data.

I'm not sure why there are update irregularities as you observe, it should update the positions every 10 seconds.

Cheers

- Balt

kiek

Quote from: Balt on Thu, 14 Jan 2016 12:53
it should update the positions every 10 seconds.
That's certainly not the case. I measured again, its two times about 8.7 seconds and then about 18 seconds.
Here is a sample:
... - 8.0 - 17.9 - 8.7 - 8.7 - 17.7 - 9.0 - 8,7 - 18.3 - 8.7 - 8.3 - 18.0 ...

Could you have a look at your code?

Cheers,
Nico

Hardy Heinlin

Related with Nagle's algorithm perhaps? Probably not.


|-|

kiek

Quote from: Hardy Heinlin on Fri, 15 Jan 2016 09:14
Related with Nagle's algorithm perhaps?
No, the information exchange between RealTraffic and PSXseeconTraffic goes locally via UDP.

Nico

Balt

I don't think Nagle has anything to do with this, but internet network latency in general will, as will latency by the flight tracking site.

The update algorithm thread in RealTraffic fetches new data if more than 9000ms have elapsed since the last query, or if no query has ever run. It is possible that at times of lots of network traffic, the traffic server times out.

But more importantly, the times you are reporting cannot be correct, as an update will never fire at 8700ms intervals... it takes at least 9000ms + latency of the traffic fetching, usually another 1 second or so. The general order of your observations however is correct: it's going to be multiples of ~9s.

Can't you time stamp the data when you receive it and extrapolate from there?

Cheers

- Balt

kiek

Hi Balt,
Quote from: Balt on Sat, 16 Jan 2016 01:29
The update algorithm thread in RealTraffic fetches new data if more than 9000ms have elapsed since the last query, or if no query has ever run. It is possible that at times of lots of network traffic, the traffic server times out.
It seems very unlikely to me that these "times out" always happen in a fixed pattern. In all my logs I see that I get data after +/- 9 secs, then after +/- 9 secs and then after +/- 18 seconds, and this pattern is repeating again and again...

Quote from: Balt on Sat, 16 Jan 2016 01:29
But more importantly, the times you are reporting cannot be correct, as an update will never fire at 8700ms intervals... it takes at least 9000ms + latency of the traffic fetching, usually another 1 second or so. The general order of your observations however is correct: it's going to be multiples of ~9s.
This 8700 ms was computed based on my internal software clock which was running a little bit too fast, after some adjustments I get +/- 9 seconds.

Quote from: Balt on Sat, 16 Jan 2016 01:29
Can't you time stamp the data when you receive it and extrapolate from there?
I already do that because I buffer incoming data 40 seconds and give them time stamps based on receival. But it looks to me that I may be have to reposition the incoming data in a fixed pattern of 9 seconds, to get rid of delays.

But even then I get strange disruptions. An aircraft flying cruize at a fixed ground speed with a fixed heading crosses say 1.2 nm in 9 seconds, but in the next leg of 9 seconds it crosses only 0.4 nm...(based on the lat/lon data). How come ???

Cheers,
Nico

kiek

Hi Balt,
Quote from: Balt on Sat, 16 Jan 2016 01:29
The update algorithm thread in RealTraffic fetches new data if more than 9000ms have elapsed since the last query, or if no query has ever run. It is possible that at times of lots of network traffic, the traffic server times out.
Any ideas yet why your program outputs traffic data in the ForeFlight stream in a fixed (repeated) schema of 9 secs, 9 secs and 18 seconds?
This means that I miss every third datapoint. When taxiing, 18 seconds before a new update is very long.
My Android FlightRadar24 app shows new data every 8/9 seconds ...

If it is not your program, maybe you could ask your data-provider why this happens (especially if this is a payware service).

Cheers,
Nico

GodAtum


Zapp

Nope, the site is down atm. I was enquiring for registering ....

Andrea

kiek


Balt

Thanks for letting me know. Our hosting department's been having issues in the past weeks. The server should be up again now.

Cheers

- Balt

Balt

RealTraffic v5 is now in BETA and can be downloaded from here: http://www.inside.net/ss/realtraffic-for-psx/ Version 5 allows you to select any time offset within 48h of the present time and that's the traffic you can then fly with.

While the vast majority of all users are flying RealTraffic in the P3D and FSX worlds thanks to Nico's fantastic PSXseecontraffic addon, let's not forget that it was originally written for, and still is written for the mother, father, godfather, and bestest of all desktop simulators, PSX!

Enjoy!

kiek

In the beta test it turned out that PSXseeconTrafic also needs the historical QNH, otherwise aircraft may not land and take-off correctly. Balt and I are working on a solution.

kiek

The solution has been found, use PSXseeconTraffic v7.0 beta and RealTraffic 5.0.4 beta.