Printable View
That's the reason why I said take a spline.
Maybe it is a little bit complicated to program as you have to solve some matrices but all in all I think you will get a result of +/- 0,2 % N1 I think with just a few values.
That accuracy should be enough.
I tested it around 1,5 hours and found a lot of problems:
- Cannot set both QNH decimal points in SIOC creator. No setting box appears if clicking on the graphic.
- EFIS "Long push=pull" is not saved. If I click again on the encoder, the option box is unchecked.
- Right EFIS is still INOP.
- Mectric Alt is INOP.
- If I push the EFIS QNH encoder, no "STD" is displayed.
- Direction of encoders is not working. I have some encoders which need a "-1" that the value goes in the other direction. Or am I making a mistake by entering "-1"? How can I set a direction?
- Sepearte thrust levers would be nice.
- If I press APU Start before the flap is open, I can see N1 increasing if the flap comes open, then N1 goes down to 0 % and N1 increases again. APU comes available. Just optical issue.
- Both PFDs have less than 1 fps! It's unflyable.
- SD: Fuel used is INOP. Maybe just FSX function?
- Sometimes I got I lot of error messages from FMGS server: "Access violation at address 004FE6CF in module 'FMGS Server.exe'. Read of address 00000074."
Is there any moment when your FMGS has no control of flight controls? I wrote my own FBW software to use my gameport joysticks with sidestick priority. Even if AP was disconnected I got control problems. When I closed your AP/FBW program it worked. Unchecking your own FBW function did not solve the problem. I think your AP/FBW and my FBW have some trouble with each other.
So if there is any time, when your software has no control of the flight controls I would be nice if it could write a FSUIPC value. So my software could recognize if it is allowed to control or not.
Unfortunately it was unflyable today... Also got problems with AP which shot me into low earth orbit :D (Maybe performance?)
Got another problem: After starting MCDU and SD on both appeared the message " '' is not a valid boolean value.".
Tried to restart it but without success.
Hello,
I'm away for the weekend, I'll check all those problems when I have a better computer than my iPhone ;)
JeeHell
Hi Kikigey.
I had the same trouble.
Check if the version of MCDU and FMGS server are the same and updated.
Regards
JeanLucques
Hello,
I will check all your SIOC problems with my hardware, and correct the SIOC creator issues (decimal points, long push, encoder direction which should be 1 or -1 as you did).
By the way, just to be sure, STD is achieved by pulling (or long pushing ;) ) the encoder.
Metric Alt is not yet available at all, and not planned for the next release. Unless a lot of russian simmers beg for it ;)
Separate thrust:I will see if I can easily add that in next release, without being too unrealistic (for example, engine failures and all are not yet planned, but the LVR ASYNC will be displayed)
PFDs: maybe it is because of FSUIPC if they are on a network (which is the case on your sim I guess). Check if FSUIPC updates frequently enough, maybe your network is in cause (some Wifi adaptaters seem not to work correctly with FSUIPC, I had the case and it is documented in wideclient documentation if I recall correctly). On my setup, I can launch FSX and the whole suite without fps problems.
SD: yes I think the fuel used offset is FSX only, I'll see if I can find a workaround.
"Access violation" and "not valid boolean" errors : hard to tell why, I guess some part of my code is not clean and tries to read an address in memory already freed... If you have any idea when it happens the most frequently?
FBW troubles: well for the time being, the FBW module ALWAYS has control over the govern offsets. In AP mode, it is obvious why, in manual mode, the FBW maintain a path (i.e. FPA and roll angle) so it needs to use the governs at all times as well. If you check 'no FBW' then the software applies the joystick input to the offset, with the sensitivity correction as well. I will try to see if I can leave completely alone the governs' offsets if you use 'no fbw' option, but if you want to use my manual mode, that won't be possible.
If you tell me exactly what you need for your own software, maybe we can find a workaround?
For the last AP issue, what was the phase of flight?
@JehanLucques:
Maybe I started the wrong FMGS server. My 2 folders of an old and the new version are named almost identical... Will check it the next time.
@ jeehell:
Metric Alt and seperate thrust levers are not important ;) I just wrote down what might be a bug or could be interesting.
PFD: Yep, I'm running it via network. Will check if there is any solution on that.
I noticed the access violation after my flight. So I cannot tell you, when it appeared. Maybe I can perform some test flights the next weekend and pay attention when it appears.
My FBW software writes aileron, elevator, rudder and brake values. If you could add an option where I can turn the raw joystick input off it would be great. Then you could add a FSUIPC offset where I can read if your software has control of the flight controls. So if AP is active there could be a "1" for blocked controls. If your FBW or joystick input is active, there should be a "1", too, for blocked controls. Just if FBW and raw input is off, there should be a "0". In that case my own software would set the controls.
So I would turn your FBW and raw input off to use my own FBW software. When I activate the AP, the offset is set to "1" and my software knows 'now I have no further control because AP is active' (or your FBW/raw input is active) and my software will write no further values so that your software has full authority.
It was initial climb. I rotated, retracted the gear, flew a few hundred feets manually and then engaged the AP for initial climb to 5000 ft. I engaged OP CLB and the pitch angle increased for a VS of around 8000 ft/min. Maybe the problem is caused by the missing of real aircraft performance and/or the presence of my FBW software.
Hi, i would like to see this implementation, i suggest you to make all instruments in one openGL window that we can expand over multi monitors if we want.
The benefit of this would be we can use the display transfer feature in our bus! Like expanded mode in Project Magenta, where you open the window maximize that open the menu and select witch instrument to display.
Hi,
This one is quite difficult for the moment. In the (far) future, I plan to mix the PFD and ND in one exe and the SD and EWD in another one, so switching will be possible, but for the time being it is not possible. I have some CPU limitations with the openGL component I use which I haven't been able to bypass yet.
If you really need the switching thing, I could perhaps do some tweaking such as "physically" moving the ND window where the PFD window is and vice versa?
Anyway, it'll be in a few versions at least, not in next version which is due very soon I hope (with the latest bug you had corrected)
Cheers,
JeeHell
It would be a nice trick i think and can work, we could try.Quote:
Originally Posted by jeehell
Okay, I'll see what I can do in a future release. For the time being, the beta 9 is out, see the new topic.
JeeHell
Hello all,
The beta 9 is out, check it out here: http://www.jeehell.org/A320FMGS_B9.zip
What's new:
-New font for all DUs, a big thank to Christoph Paulus (aka Kikigey89)!!!! (you have to manually install the airbusfmgs.ttf font in your c:\windows\font folder). You have to set the font for each DU separately (see in the options of each DU).
-PFD layout reworked
-N1 swing corrected
-Seatbelt and No Smoking signs for FS9
-FPLN point sequencing when several pseudo waypoints between ACFT and Active Point
-APPR phase activated when overflying DECEL pseudo waypoint
-PERF pages change when flight phase changes
-FO EFIS NAV1 and NAV2 bug corrected
-Joystick input is directly sent to FS when FBW is deactivated and AP is disengaged. An offset is available to know when joystick is "free"
-FDS FCU glare 3 integration (check FDS_Glare folder)
Again thank you Christoph for the font!
Have fun,
JeeHell
ok nice to see that finally you changed the font and made many other changes!!! keep up the good work mate
Looks really cool :) I'm proud of myself :D But nevertheless the font isn't finished. If I get new pictures of the MCDU I will improve my font.
Just one issue: If I want to select the font in both PFDs, a message appears which says that no font is installed. So I cannot change the font.
But if I restart the PFD, my Airbus font is active, don't know why. But it's good that it has changed itself :P
Currently I am not able to test in my cockpit because I disassembled my MCDU to make a board which will carry all the buttons.
I think this will take up to a month. But tomorrow I want to test your FMGS with FSX and FSX's A321 to get an idea of how it should work :D
After that I will perform the same flight in FS9 to tell you, where the problems are.
Hi to all who are reading this ;)
Today I had just time for testing the FMGS in FSX with default FSX's A321. I spend around 5-6 hours on disigning my new pedestal. Picture here: http://picasaweb.google.com/kikigey8...85195423395362.
Now to my bug and improvement report:
- Background color should be the same on all DUs. Especially PFD background is complete black, the others have a light black. Check that all have the same background color (light black looks good!).
- An option for realtime alignment of the IRS would be nice.
- INIT page is accessible every time. I think in reality it's only accessible on ground.
- No distance values to destination in MCDU.
- VS does not fit in FMA space (see screenshot).
- ILS APP was activated in cruise, don't know why.
- As far as I know the name is transition level instead of transition altitude (APP page, MCDU; only for descent, on climb it's transition altitude).
- If all bugs are corrected, an ALT button instead of the EXPED button would be nice for A330 (for the future).
- Wrong ILS frequency displayed on PFD. I had to set it manually in the MCDU but on PFD the wrong frequency was shown.
- ILS CRS cannot be changed in MCDU.
- Airports are not visible on MCDU. As far as I know the departure an destination airport are always visible.
- Discovered a lot of circles on ND (see screenshot).
And know the biggest bug: I had some problems with OP CLB, OP DES and Alt hold. The aircraft was luffing a lot, sometimes up to +/- 10°. I made a video, available on http://www.christophpaulus.com/files/fmgs.avi.
Another problem was when I selected 30000 ft (was on 28000 ft) the pitch extremly increased and I got a VS of around 14000 ft/min... After a few seconds the pitch decreased and the aircraft descended because I have been shot up to 31000 ft. But the VS mode works good, there are just a few problems if I change the VS. Then the aircraft starts to luffing again but stabilizes after a few seconds.
Maybe you could use the built-in AP of FS? I think this would solve a lot of vertical mode problems. You could use it for altitude hold and for VS operations. Maybe you can also realize OP CLB and OP DES via FS VS mode. I think vasFMC uses this, too, and this works almost perfect and smooth.
I saw that the values on the FCU in FSX are changed if I change them in your FMGS. But no AP was active yet, just A/THR. I guess you have realized the SPD hold function via FS?
Chris
I also can't change the font in PFDs, another small glicth is i had to delete all the config in the subfolders 'cause the screens was out of view and mcdu was not visible, i think you have saved your screen configuration then distribuited the fmgs.
Just to let you know a first user can go crazy...
Hello Christoph,
Nice design for your pedestal!
Yep I noticed that, I'll put the light black (sounds weird ;)) back.Quote:
Originally Posted by kikigey89
Are you reading my mind? I've started programming the ADIRS yesterday!!Quote:
Originally Posted by kikigey89
I let this "bug" intentionally, as a way to supervisor a few thing for debug, but I don't need it anymore, I'll try not to forget this one.Quote:
Originally Posted by kikigey89
I'll correct thatQuote:
Originally Posted by kikigey89
Damn font larger than Arial ;)Quote:
Originally Posted by kikigey89
The approach type appears when you enter the APPR (and STAR) in the MCDU. I need to check exactly how it works on the real unit.Quote:
Originally Posted by kikigey89
I've just checked on my MCDU documentation, and it remains labeled as transition altitude...Quote:
Originally Posted by kikigey89
I guess the FMGS computes the transition FL from the transition altitude and the selected QNH, I'll check that.
The exped button is inop for the time being.Quote:
Originally Posted by kikigey89
What is the purpose of the ALT button on the A330? (it does not exist on the A320)
Yes autotune is not implemented yet. As for the PFD frequency, I'll check and correct.Quote:
Originally Posted by kikigey89
As in the real A320 I think. I'll check.Quote:
Originally Posted by kikigey89
Well the DEP and DEST runways are not yet implemented, not such an easy one. I'll see what I can do.Quote:
Originally Posted by kikigey89
Yes, an old bug, but had not bothered to correct it yet.Quote:
Originally Posted by kikigey89
I'll see if I can correct this one and the wrong circles on some turns as well.
I might be faulty on this one, I haven't changed the AP/FBW coefficients for a long time concerning the default A321, I probably need to tune them again.Quote:
Originally Posted by kikigey89
If you want to try again, use the iFDG coeffs.
In the early design I used the FS AP but it is really not a realistic way to do it in my opinion: I couldn't maintain a selected speed with the A/THR maintaining a constant N1 (A/THR in thrust mode), and so the A/THR would increase/decrease N1 and the VS/FPA was not exactly right (either to big or too small...).Quote:
Originally Posted by kikigey89
I nonetheless use the FS ATHR as you said, but only when in SPD mode (in ALT, V/S or ILS mode), not when in THR mode (i.e. in CLB or OP CLB mode). But I wish I could not use FS at all, their ATHR is quite slow to react sometimes I think.
Anyway, try with the ifdg coefficients, and tell me if it's still bad. I'll try to make better coeff for the default A321 in next version.
By the way, why don't you use the anitaliasing? the DUs would look better I think?
Hello Davide,
I've been told for the PFD font. If you try to change it, close the PFD and start again it should work. I'll correct that in next version.
For the windows not appearing, maybe you tried to use your old configuration file. I changed the format of this one to add the font function, that's probably why.
Do you have better results with the FDS module now? If you still have bugs, advise me ;)
Hi,
as far as I know the ALT button is just for the altitude hold function. The EXPED function is missing in the A330/A340.
You are the master of your software and you know, what's intentionally and what's not. And you know more about the MCDU. I just noticed some things where I thought they might be wrong. So just forget these things where you know, that you are right :) I write everything down that I discover and post it here.
Same with FS AP: I was just wondering why you are not using this function. But your N1 hold is great, I hope someday everything will work properly and N1 will not go up and down the entire time in cruise (SPD mode) like in vasFMC. That was very funny at our winter event. We were working in shifts and if you were in bed in the upper floor, you could hear the engines spooling up and down :D
I hope your FMGS will work with my aircraft and with FS9 until my planned summer event in mid of august. At least 120 hours non-stop on VATSIM - Great :)
I will try it again with iFDG coefficients. Maybe not tomorrow because I planned to go gliding. I haven't been in air for 3 weeks and I need to go flying :D But it should rain tomorrow...
It's a good question why I am not using antialiasing... I think I just forgot it. I have some problems with AA on my cockpit computers and I need some time to solve that issue to get AA in the cockpit. So the view of the display here on my home computer was as normal as in the cockpit :P
Back from the airfield I tested the entire config with iFDG coeff. and it worked almost perfect!
In OP CLB the aircraft was luffing just a litte bit (+/- 2°) and in cruise it was completely stable :)
Tomorrow a test in FS9 with iFDG is coming up.
Good :)
I toyed around the coeffs today, and I'm quite happy. It seems the iFDG coeffs work pretty good with the default FSX A321, so it might mean that those coefficients are "generic", for this range of aircraft (probably fits the B737, and even bigger aircraft as well).
I found out that the OPCLB coeffs can be enhanced, try those values:
OPCLBiasKp=0.005
OPCLBiasTd=10
With these, I almost had no swing at all during normal climb!
Cheers,
JeeHell
Great :) Will test it this evening.
If this works, I maybe have to edit this values for my A332 so it will be great, if you can explain them in your manual.
So I can pay attention to the behaviour that will change by this value instead of monitoring the entire behaviour.
Hi, found some bugs, cruise set at fl270 near fl250 aircraft start a nose up attitude of 3000vs loosing speed and engines spooling at MCT i think, this happened until altitude captured at level 270.
Another thing is at 10.000ft aircraft set VS at 0 to accelerate but i think a reduction to 1000 or 1500 will be better.
MCDU screen sometimes is not going up with the flight plan so i have to push button fpln to bring it up(so the white waypoint is at 2nd rlsk.
Edited the values as you said for coefficient, used FS9 and ifdg model all is stable.
Can't have time to test FCU, but will do.
Hello,
Yes those are bugs/limitations, I will try to correct them. The VNAV model is not yet perfect.
Good to hear the AP/FBW works Ok, it has been a long run :D
kiki: I will add a few lines in the manual for the tuning of coefficients.
Thanks :)
I found some time to test it in FS9 and it works perfectly :)
Okay, except those FSUIPC offsets that are not supported by FS9 and except the reported bugs. But the VNAV was brilliant with these new coefficients.
I think most flight problems are caused by this values which have to be adapt for every aircraft.
In the MCDU there is a small bug: I enter a direct but if pressing "Insert" the direct isn't inserted. Just on the second try it works.
Okay good to hear.
For the "insert twice" bug, I found the problem already, and will be corrected in next version ;)
I just need to work on your new font, and I will soon release a new version (next week probably, won't be home for the weekend...)
Cheers, JL
:) No problem, I'm planning to build my new pedestal on friday/saturday
Hello,
The version B10 is now available:
http://www.jeehell.org/A320FMGS_B10.zip
Whats new:
-New fonts for all DUs:MCDU and EIS separately, a big thank to Christoph Paulus!!!! (you have to manually install both fonts in your c:\windows\font folder). You have to set the font for each DU separately (see in the options of each DU).
-ADIRS
-FPLN bug having to do every modification twice corrected.
-FPLN sequencing with pseudo waypoints should work better.
-Descent managed speed will be more stable (less movements in pitch).
As usual, you're free to report your problems!!!:mrgreen:
Cheers,
JeeHell
Thread closed, new version is available, see the new thread!
you are well on your way to converting me to a bus driver. never thought I'd say that out loud.
Andy Smith
The first step is to admit you were born a bus driver. Then you tell your family, and finally the shame will turn into pride ;)
It looks great in my cockpit! But I found one bug:
The window options of the FO PFD window (hide border, always on top and lock position) are not saved and after restart I have to check these 3 manually again.
The framerate problem is caused by my cockpit computers. If I run just 1 PFD without NDs the framerate is approx. 10 fps. The more windows I open (second PFD, NDs) the more the framerate is decreasing. I will look for a new computer.
You added this FSUIPC offset where I can read the state of the FBW module but I need an option where I can turnoff the entire module so that my software can take full control. And for this I need a value where I can read if your FMGS has control (in my case by AP) or not.
Example: I turnoff the entire input-module by a checkbox or something else. Then I start my FBW software. We are on ground so AP is off and because the input-module is offline the value (lets call it X) is 0. My software knows that your FMGS has no control. Then I take off with my software and shortly after initial climb I activate the AP. Then X changes to 1 and my software knows that your FMGS has control and my software will stand by.
X should also be 1 if the input-module is active. It doesn't matter if FBW or raw input is choosen but your software has control. X should only be 0 if AP is off and no input-module of your software is controlling the aircraft.
Hello Chris,
I will correct the FO PFD issue.
For your FBW problem:
Maybe we do not understand each other on this one :) but right now here is how the software works:
if offset $66D9 is 0 the AP/FBW module has control (whether because AP or FBW is ON)
if offset $66D9 is 1 the AP/FBW module does NOT have control: FS receives directly the joystick input, without any intermediary (so AP and FBW are both OFF)
the offset $66D8 allows you to switch FBW ON/OFF without having to click the checkbox, but I did change the handlign of the joystick in the AP/FBW module: with AP OFF and FBW OFF, my software sends nothing to FS.
Alright, thanks, that's exactly what I need.
Maybe I'm a little bit confused by all those FBW, joystick and AP things :P
What came to my mind what is important for my homecockpit:
I need to transfer the sounds on another computer than the FMGS server (flightsim) computer.
So it is possible for you to add a sound application which communicates with FMGS server and plays the sounds on another external computer?
Hello,
I had this idea already, but I haven't had the time to implement it yet. Since at least one more person is interested, I guess it's a nice one ;-)
Maybe not in next version, as it seems B10 is quite not as stable as it should, I will soon release B11 to correct some big bugs.
JL
Thanks :)
For the use of your FMGS at my summer event in mid august this is very important but more important are some new bugs in B10.
I made a testflight an hour ago but had to cancel it on approch due the AP and ATHR problems.
The aircraft was luffing again but at a long period of time. One period took about approx. 30-45 secs. Don't know if it's caused by the coefficinets as before or by a problem in the software itself. Furthermore after activating the AP my VS increased dramatically and I got a stall. I recognized this VS problem in OP CLB, OP DES and when VS is set manually. All the times I overshot my selected flight level by 2000-3000 ft. This happens on climb and descent. Record of VS was 13500 ft/min :D
I used iFDG A320 with the same overall config as in my test with B9.
Some other problems, errors and suggestions:
- Landing weight lower than ZFW (MCDU)
- SD error: "'-9223372036854775808' is not a valid integer value." (I think this occurs if FS is paused)
- Status page on SD would be nice
- EFOB calculated to -1.4? (Fuel available at least for 2 testflights)
- Pitch trim increases during taxi
- MCDU sets new CRZ ALT to FL240 but FL230 was entered and selected
- Moving of VOR and ADF needles would be nice (as in real and like in vasFMC)
- MCDU: Arrival time was calculated to 00:02 UTC which is about 12 hours after my estimated landing time :D
- GW in FS9
But nevertheless: Thank you for that software and for working so hard on it! :)
I made some screenshots for you: http://www.christophpaulus.com/files...creenshots.zip
That's weird. Have you ever had that in previous versions?Quote:
Originally Posted by kikigey89
For all of the other problems, I have already identified them and corrected most of them. I hope the new version will be out this week!
Only the VOR/ADF needles, what do you mean by "moving of the needles"?
JL.
No, B9 was perfect. I will take a look on the config if something's wrong there. Maybe I can perform a second test this evening.
I mean that the needles are not fixed and pointing exactly to the VOR or NDB. As in real the heading to the station is deviating a little bit by some degrees.
So the needle is not pointing at let me say 240° (which is the correct heading) but a few seconds on 238° then maybe some secs on 241° one sec an 237° a few on 240° and so on.
Ok I see for the needles, but I think we have some more important suff going on such as pitch problems ;)
By the way, I think I pinned that problem, but what is weird is that it should have occured on earlier version as well, I think it is related to FS9 version of FSUIPC which doesnt "protect" the offsets the same way as in FSX...