A320 FMGS beta 30

Thanks JL!

once again a great Christmas present from you :)
Merry Christmas to all,

Tommi

The best present... thank you JL
Merry Christmas to all...

Attachment 7354Attachment 7355Attachment 7356Attachment 7357Attachment 7358Attachment 7359hi , jeehell

I am new at this discussions , but I have been building a A320 simulator for a quite long time (9 years) I have made everything my self ( I only bought opencockpits cards ) but I had a problem with software , being al of them quite expensive , but I found your software and I can asure that this was the best christmas gift ever. thanks a lot .

merry christmas to you all.

Quote:

---

Originally Posted by pipostar

I am new at this discussions , but I have been building a A320 simulator for a quite long time (9 years) I have made everything my self ( I only bought opencockpits cards ) but I had a problem with software , being al of them quite expensive , but I found your software and I can asure that this was the best christmas gift ever. thanks a lot .
merry christmas to you all.

---

Welcome and well done...:roll:

Quote:

---

Originally Posted by Leonidas

Welcome and well done...:roll:

---

thank you leonidas and by the way , can´t download b28 , I will try tomorow.

So, after some tests with B.28:
Minor issues:
1. CPFlight FCU leds turning on after the 2nd starterfsx start.
2. ND (both CPT and F/O) doesn't start if I restart FMGS server. I have to restart clients too, in order to start.

Major issues:
1. 1-2sec lag for FCU and >2sec for thrust levers. I've tried without a piece of hardware simultaneously to find out why, but it's the same with or without FCU, Thrust Levers or FDS card. Network utilization is 1% for server and 1-4% for clients.
2. Frame loss at the 6 client displays not at server's scenery.
:cry::cry::cry::cry::cry::cry:

Regards

Hi Leonidas,

Since you use FSCockpit THR LVRs, could you try (just to test if it makes a difference) to use a regular USB joystick axis instead of those and also remove the FScockpit_JH.dll from hardware modules folder?

JL

Quote:

---

Originally Posted by jeehell

Hi Leonidas,
Since you use FSCockpit THR LVRs, could you try (just to test if it makes a difference) to use a regular USB joystick axis instead of those and also remove the FScockpit_JH.dll from hardware modules folder?
JL

---

Hi JL
I don't have such a joystick, but I've done something else. I renamed the FScockpit_JH.dll and then I started FS and FMGS server. This is the same, isn't it? So, there was lag at FCU 1-2sec and frame loss as I wrote.
Regards

Yes it should be OK. When renaming, you removed the DLL extension? if you kept the file with dll extension then it was loaded as if it was still there.

JL

Quote:

---

Originally Posted by jeehell

Yes it should be OK. When renaming, you removed the DLL extension? if you kept the file with dll extension then it was loaded as if it was still there.
JL

---

No, I didn't. I'll try and feedback.
Regards

Hallo JL,

Thanks for the Christmas present. After a few tests, I mean the delay issues are resolved. The Chrono switch from FO does not work anymore, but that's not a big problem. Which modules should be installed on which computers? What is your recommendation for a 4 PC system? Really great work, again many thanks.

greetings from Germany Micha

Quote:

---

Originally Posted by jeehell

Yes it should be OK. When renaming, you removed the DLL extension? if you kept the file with dll extension then it was loaded as if it was still there.
JL

---

I tested it. It's the same. I'll double the RAM these days and I'll try again.
Regards

Before udating any hardware, can you try one last thing:
do not run the hardwareConnect software (or clsoe it after launching starter soft). And use the software FCU/OVHD to see if there is any difference.

JL

Quote:

---

Originally Posted by jeehell

Before udating any hardware, can you try one last thing:
do not run the hardwareConnect software (or clsoe it after launching starter soft). And use the software FCU/OVHD to see if there is any difference.
JL

---

As you said, I closed the HardwareConnect and I used software FCU. It was excactly the same: FCU like MCDU 1-2sec lag, but OVHD is rapid...:(

Were the FCU and MCDU on the main PC or on a remote PC?
And same question for the OVHD?

You can also check if you lack memory from ctrl-alt-del then performance tab, it gives you an overview of used memory. If you're above 90% then it might not enough, otherwise I think the problem is somewhere else...

JL

Quote:

---

Originally Posted by jeehell

Were the FCU and MCDU on the main PC or on a remote PC?
And same question for the OVHD?
You can also check if you lack memory from ctrl-alt-del then performance tab, it gives you an overview of used memory. If you're above 90% then it might not enough, otherwise I think the problem is somewhere else...
JL

---

All are on main PC. Memory use is 30-40%
Regards

Hmm please do a last test: run only server computer without hardware, then check if there is lag. If not, run the remote computers one at a time until lag appears.
Check if lag is induced by the number of clients, or if it is specific to one of your clients PC.

This is really weird the software FCU lags on the main computer but not the OVHD??

JL

Hi JL,

thanks for the update to 28. I have made the update with the automatic update function (updater.exe) on both PCs. I have done some tests on the ground, and it looks as if the light switches on the OVHD are not working for me:

- Logo light does not switch on logo (and cabin) light on aircraft (using Project Airbus)
- Beacon does not switch on beacon light on aircraft
- The same for strobes and landing lights. When switching on strobes, also the message "strobe lights off" on SD does not disappear

The position of the switch is changing, but there is no reaction. The rest of the OVHD seems to work (APU switch etc).

I have tested as well with old v27, and there everything is working fine. Anyone an idea?

Thanks
Stefan

I can confirm this but when I press the start button for the APU, the light illuminates but the APU does not start. I run the OVHD.exe on a client. I've heard it will work if the OVHD.exe is running on the server.

What is CockpitPassion, ComplexJoy and Complex THR LVR Joysticks?
Thanks

CockpitPassion is a website in France that sells Airbus panels for home cockpits:

Here is the Link: Accueil

CockpitPassion is a French Hardware manufacturer Accueil
ComplexJoy is a small utility to be able to artificially mix two analog axis (or one axis and a reverse switch) into a single virtual axis. Used mainly for those with goflight quadrants, or some throttle quadrants which use two axis (one for resverse one for normal range).
Do not install those if you don't need them (and I guess you don't need them...), particularly the cockpitpassion one, it can slow down the hardware connect soft if it cannot find real hardware attached.

JL

Quote:

---

Originally Posted by jeehell

Hmm please do a last test: run only server computer without hardware, then check if there is lag. If not, run the remote computers one at a time until lag appears.
Check if lag is induced by the number of clients, or if it is specific to one of your clients PC.
This is really weird the software FCU lags on the main computer but not the OVHD??
JL

---

I run it without h/w only on main pc, but before this, I doubled ram from 6 to 12GB. So, not instant like OVHD, but big improvement FCU/MCDU lag is now <1sec. Only THR/LVR lag is still 1-3 sec. No matter if I connect none, one or more pc.
Regards

PS. I forgot to say that I've made a clean installation.

Tell me again, what is your main computer CPU?
How much CPU % is FMGS server taking? How many CPU% used in total?
Did you assign a fixed CPU core to FMGS server? (you must NOT do that)
Do you have any other software not related to the FMGS which may use a lot of CPU?

JL

Hi all,

An update is available through automatic updater, to correct OVHD switches issue.
I'll try to put a full installer online tomorrow.

Regards,
JL

Quote:

---

Originally Posted by jeehell

Tell me again, what is your main computer CPU?
How much CPU % is FMGS server taking? How many CPU% used in total?
Did you assign a fixed CPU core to FMGS server? (you must NOT do that)
Do you have any other software not related to the FMGS which may use a lot of CPU?
JL

---

Core i7 820 2.8GHz (overclocked to 3.4GHz).
FMGS=13%, FSX=0-12%, Idle Process=75-87%, CPU usage=25-60% (when overclocked=10-50%).
I didn't understand third question.
No, I don't.

Regards

Quote:

---

Originally Posted by jeehell

Hi all,

An update is available through automatic updater, to correct OVHD switches issue.
I'll try to put a full installer online tomorrow.

Regards,
JL

---

Hi JL

First thanks for your great software and the newst fix for the OVHD.
But now i have on the ND, which is running on the Client some problemes. I can't see the route. If I start it on the Server its running normaly.

Regards

Quote:

---

Originally Posted by jeehell

Hi all,
An update is available through automatic updater, to correct OVHD switches issue.
I'll try to put a full installer online tomorrow.
Regards,
JL

---

Hi JL
After this update black screens are instead of: PFD, ND and E/WD. SD works with many problems and FCU is frozen. Please where could I download last version of B.26, because I lost it? It was the last flyable version for me. Thanks
Regards

Hi,

@Beret: Can you check WideFMGS client is connected to the server? (to open it, you have to click the icon which is "hidden" in the tray bar, next to the clock in the task bar).

@Leonidas: Same for you, check that the widefmgs soft is correctly connected.
Also, considering your computer it should be able to run ALL ot he software by itself without sweating, I can do it on my computer which is almost similar (core i7 @ 2.8GHz, no OC, 16GB of RAM). So I really believe you might do something or something's wrong with your computer. Let me rephrase the 3rd question:
It is possible (with Windows directly or with some other software which can do that) to set what is called processor affinity. This means to tell windows to use only one (or a few cores) only for that software. The FMGS server being multithreaded, it works much better if it is not set to run on a limited number of cores.

I will see if I can find an old B26, check your email.

Regards,
JL

Hello JL,

After the update I have the same problem as Leonidas. On Client1 no Cpt PFD, ND. On Client2 no EWD, SD, but Stby an MCDU is on. I have changed nothing in my system. WideFMGS works on all PCs, I check this in the Taskmanager.

Regards,
Micha

Quote:

---

Originally Posted by jeehell

Hi,

@Beret: Can you check WideFMGS client is connected to the server? (to open it, you have to click the icon which is "hidden" in the tray bar, next to the clock in the task bar).

JL

---

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

Regards

Quote:

---

Originally Posted by jeehell

Hi,

@Beret: Can you check WideFMGS client is connected to the server? (to open it, you have to click the icon which is "hidden" in the tray bar, next to the clock in the task bar).

JL

---

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

Regards

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

Attachment 7371

Regards

Hi,

Ok it's what I thought, I'm looking into the disconnection bugs.

JL

Hi All

an automatic update is available, hopefully solving all those network comm issues.
I'm working on uploading a full install package as well.

http://www.jeehell.org/A320FMGS_B28.2.exe

Cheers,
JL

Happy New Year to all of you!

Hi JL! I just tried your new b28.2. My first try with any of the b28 versions as I didnt have the time in the last days. I also have some connections problems now which I didnt have before. :(
Intresting is that I now have to start the client before the main server. Otherwise it does not get any connection and the widefmgs box on the client remains completly white. When connected it pops some fail numbers once in a while and disconnects and connects.
In b27 I was able to start in any order the server and client.
I addition I see some lags wrt throttle lever position. <1 sec. The hardware throttle is connected to main machine. The EWD is on the client.
Have not seen these lags in b27. And the ND on my client became very unstable. It crashes within less than every 5 mins.

And ... really weird... I somehow managed to see the two EPR gauges on the top of the EWD. How did I do that?? Second start of EWD and I see the "old" N1 gauges? Have you touched these? please enlighten me! :)

Happy new year, JL!!!

Thanks!
Rob

Quote:

---

Originally Posted by AirFan

[...] Intresting is that I now have to start the client before the main server. [...]
[...] And the ND on my client became very unstable. It crashes within less than every 5 mins. [...]

---

Also Happy New Year to all!

I installed version 28.2 from scratch. As reported by AirFan, I also see the same things happening on my machine. In addition, if I stop the WideFMGS on the server, the client WideFMGS may crash (and vice versa) once they are connected.

In addition, my CPFlight FCU dosn't work (digits cannot be changed, but when making changes, I can see new entries in the log). The FCU is connected to the FSX server. I executed the programs as follows:
1. Starting FSX
2. Starting A320 FMGS Starter
-> In the hardware log I can see:

C:Created
C:Get Analog Proc
CPFlight:Port opened
CPFlight:Connected

3. Starting Overhead and MCDU on a client PC
4. Switch on 'Battery' in Overhead
-> Several data are sent to the FCU successfully. But then, I can see the following entries in the log:

[...]
CPFlight:SendOK:X1005
C:Created
C:Get Analog Proc
CPFlight:Unable to open com port
CPFlight:System Error. Code: 5.
Access is denied
CPFlight:CE_WriteFailed
CPFlight:SetupComm function failed
CPFlight:System Error. Code: 6.
The handle is invalid
[...]

The full log is attached.

I changed the port in the configuration file. The CPFlight FCU runs the lates firmware version 1.12. What am I doing wrong? Since it is the very first time I installed the JeeHell FMGS, I'm sure I'm doing something wrong ...

Thanks and Regards
Adrian

Hello Adrian,

you did nothing wrong. I have the same problem with the CPFlight FCU.

Hello Jeehell,

When comes the functionality to save and restore a situation?
I am also interested to create some faults like rapid decompression. I guess the Ecam drawing are fixed and no needle are able to turn.

Chris

Hi JL
I did some investigation into the TCP/IP communication between WideFMGSServer and WideFMGS. It looks like the WideFMGSServer is not able to process the data received fast enough. Hence, the server sends "ZeroWindow" information. In that case, the client should stop sending any data. But I saw, that the client still sends data with a length of 1 byte. Following the trace out of Wireshark:

Time starts 19.392726
WideFMGSServer:8004 > WideFMGS:49409 ... Win=1536 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=16
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=123
WideFMGSServer:8004 > WideFMGS:49409 ... Win=1280 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=41
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1239 -> now server buffer full
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0 -> server confirms buffer full (Win=0)
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1 -> client still sends 1 byte
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1 -> client still sends 1 byte
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=41
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=1476
WideFMGSServer:8004 > WideFMGS:49409 ... Win=3584 Len=0 -> now server has 3584 bytes free in buffer
WideFMGSServer:8004 > WideFMGS:49409 ... Win=3584 Len=1476
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=1460
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=1460
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=664 -> now server buffer will be full again (3584-1460-1460-664 = 0)
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=943 -> server sends '0' buffer left
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=0 -> 0.001 seconds later, server has free buffer
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=0
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=1312
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=1476
WideFMGS:49409 >WideFMGSServer:8004 ... Win=64756 Len=1460 -> client received 2788bytes, but only 944bytes unprocessed in buffer
-> client processes data very fast
Time ends 21.733430, elabsed time 2.34 seconds

I think the server side applications don't process the received buffers fast enough. Furthermore, I think that the client application shouldn't send any data anymore, if server reports 'buffer full'. It may cause the application to crash as the buffer will have unpredictable content. If one is interested in the TCP buffer handling, here is a good link that explains it: TCP ZeroWindow - Wireshark Q&A

I also see that data length are up to 1476 bytes in general. Adding the IP header of 20 bytes, we end up with 1496. If one uses VLAN's, then we have to add additional 4 bytes. In total it is 1500 bytes, which is the maximum Ethernet frame size (unless jumbo frames are available). In Windows 7, the MTU size is set to 1500 bytes (see command netsh interface ipv4 show subinterface). Hence, everything should be fine. But as there are different hardware (Ethernet cards, switches, routers) out there, I usually don't go over 1400 bytes for data - just to be on the save side.

While I was minitoring the traffic for about 15 minutes, I also saw 2 packages with a data size of 5280 bytes and 2351 bytes. This would definitely be too much. In such a situation, the packet needs to be splitted into multiple TCP packets by the OS / hardware. I observed this situation in other set up when I went over the MTU size in my programs. The network performance becomes so bad, that it runs like in slow motion. Please avoid sending packets larger than 1476bytes (or better 1400 bytes).

I hope my thoughts may help to overcome the network performance problem.

Regards
Adrian