PilotEdge Forums

I had not used traffic in a while so I thought I would try and replicate the problem. I found that I had not yet changed the TrafficRelay.bak file to .ini since I reinstalled PE so I did and restored the traffic function in FF.

Unfortunately I was not able to replicate the frame drop issue with Traffic on.

I also recalled that I did not reload the high res CSL's that were recently released...did that, no change.

Using 10.4 and W10 with latest PE client.

I've used Foreflight with traffic in the past but recently started using WingX again on my PilotEdge fllights. My full IFR subscription still hasn't run out yet so I am using it for geo referenced taxiing and approach charts.

John

I have attempted to simulate all configurations that I have tried the last couple of weeks and I cant replicate it. It came once for me and a full dump/reinstall of PE fixed it...

It would be nice to get this one resolved...haven't seen Helipilot do a stream with XPlane for close to a month!

stealthbob wrote:I have attempted to simulate all configurations that I have tried the last couple of weeks and I cant replicate it. It came once for me and a full dump/reinstall of PE fixed it...

It would be nice to get this one resolved...haven't seen Helipilot do a stream with XPlane for close to a month!

Same for me, only happened once and I am still using FF with the traffic and the CSLs.

The suggestion to reinstall the pilotedge client folder worked for me. Frames back to normal.

This happened to me last month until I fixed it and then seemingly randomly re-occurred again today. Frame rates normally 50+ cut down to .5 fps when connected to the Pilotedge network. I'm running X-plane 10.42.
Turns out the IP address of my iPad had changed with my last iOS update. The solution is to set the IP address in the VSProTrafficRelay.ini file to match the iPad IP address. No need to remove and reload the PE plugin.

It's so strange that the frame rate is affected by that. It's a one way UDP push. Our plugin doesn't know or care if there's a device receiving the information or not. I'm trying to work out why it would cause the frames to drop in Xplane if the IP is incorrect. I'll try to replicate this but I KNOW there have been many times where I've fired up Xplane (which is configured to push traffic to my iPad) and the iPad isn't switched on at all, and the frame rates are fine.

It is certainly strange. I tried some things tonight that may help you figure this out. If the VSProTrafficRelay.ini file IP matches the iPad's IP - AND - the iPad and Wifi is turned on, frame rates are normal. If I turn off the iPad or its Wifi connection, frame rates drop to about 0.350 fps. If the IP address in the VSProTrafficRelay.ini file is completely random there is no frame rate drop . . . BUT . . . here's what was interesting: If the IP address in the VSProTrafficRelay.ini file is not the same address as my iPad, BUT IS the same address as any other device on my wifi network AND that device is turned off, then frame rates drop. So . . . I played with this a bit and entered the IP address of my kid's laptop in the .ini file. Sure enough, when he was connected to wifi my frame rates were fine, but when he disconnected or turned his computer off they dropped. Note that the drop off in frame rates is not instantaneous. There is about a 20 second lag. But once the device is reconnected to the wireless network, the frame rate increase back to normal is instantaneous. I tried it with my wife's phone and an old iPad I had laying around too. Same result. Hope this helps you figure it out. BTW, it made no difference what IP address I put in the X-plane Network settings iPad address box, or whether on not it matched the VSPro file address. That was not a factor that affected the frame rates in any scenario I tried.

Rod

Just to add confirmation, I am able to replicate this as well.

If my iPad for some reason is connected to the wrong network I get this frame hit (2 separate routers)...once I switch over it restores.

Rod, thank you for the detailed post. I was under the impression that UDP pushes were stricly one way and that no acknowledgements were needed or sent. Hence, this makes absolutely no sense.

However, the symptoms you've describe sound consistent and repeatable, so I think that about solves it. The VSProTrafficRelay.ini file needs to be verified for correctness before running the plugin.