FlightGear altitude incorrect from SITL

I am using AP 3.5.0 SITL on a Jetson TK1 and running FlightGear on a Ubuntu 14.04 VM on my PC. When I start the SITL, the FlightGear goes to the correct lat/long, but the altitude is 0 and thus I am “underground” in most places. I have an almost identical setup on the VM itself, with the exception that the build is AP 3.5 (Beta 1). That works correctly, but it is painfully slow (since for my application I have to run it with only one processor). Also, in both cases, Mission Planner on the PC connects to either and gives the correct altitude. I have verified the starting location settings are the same (copied file from VM to Jetson), and they are using the same waypoint files as well. I also have FG on my PC native, but it does not get the updates from VM nor the Jetson, but will if I run the SITL under Cygwin (my original configuration). I suspect it is firewall/IDS issue based on company policy.

Has anyone run into a similar issue when the SITL and FlightGear are on physically different computers?

The cause of my problem was due to a couple of things:
[ol]1. I had added an entry in my Rascal.xml file to send FlightGear data to my remote PC. Apparently, this overrode code in SITL_State.cpp that took care of this (new in version 3.5).
2. I had been searching for things on my PC which was version 3.4 vs. 3.5 on the Jetson. Version 3.5 added the FlightGear output functions.[/ol]

Now that the model was not sending data directly to FG, I needed to modify SITL_State.cpp, line 102 to the IP address of the remote machine running FlightGear (e.g. fg_socket.connect("192.168.1.234", 5503); // my remote PC IP address (BTW, it works with my VM version, but the native FG on the PC does not pick up the stream; very strange. Again, it could be a IDS/Firewall issue).

Also, a minor fix: Modify line 230 to read:fdm.agl = height_agl(); // was = sfdm.altitude to call the function that determines the AGL. This way the FG HUD meters work as AGL and AMSL (before they were both the same reading).

So, while the entry sends most of the data to FG, it doesn’t know about AGL, so it always started as 0 and short-circuited the other output in SITL_State.cpp.