Jump to content
The simFlight Network Forums

GFDisplay & Go Flight MCPPro


Recommended Posts

Hi Pete,

I've been looking into using GFDisplay to display values on my Go Flight MCP Pro. In the manual it shows an example in the [GF Connections] section of GFMCP=1 indicating it has detected the device.

I'm not getting this to appear in my GFDisplay.ini file and I'm guessing that the MCP Pro is not recogised. My other Go Flight devices are detected and display correctly. Can you confirm/clarify whether the MCP Pro is supported?

Thanks

Steve

Link to comment
Share on other sites

I'm not getting this to appear in my GFDisplay.ini file and I'm guessing that the MCP Pro is not recogised. My other Go Flight devices are detected and display correctly. Can you confirm/clarify whether the MCP Pro is supported?

Yes, it is supported in the current GFDisplay release (1.24) -- it would also need the support in GFDev.dll -- maybe yours isn't up to date? I think the one in the Updates & Goodies announcement in this Forum copes with the MCP Pro.

Regards

Pete

Link to comment
Share on other sites

Hi Pete,

I had GFDev.dll v1.90.0.2 in the modules directory which also contains GFdisplay.exe. I replaced GFDev with the one from your website but still no luck, it still doesn't recognise the MCP Pro.

I have used the MCP Pro with the Goflight databridge as a normal FS Autopilot and with the LevelD 767 and it works fine. Anything else I could have done wrong?

I'm running XP64 by the way.

Thanks

Steve

Link to comment
Share on other sites

I had GFDev.dll v1.90.0.2 in the modules directory which also contains GFdisplay.exe. I replaced GFDev with the one from your website but still no luck, it still doesn't recognise the MCP Pro.

Sorry, I just checked. I was mixed up before with the similar code in WideClient and FSUIPC for reading the GoFlight devices. Both of those were updated for the MCPPro, but I've just checked, and you are correct. I never did update GFdisplay. :roll: :x

I've made a note to see to that, and will do so as soon as I can get to it -- maybe later this week. Keep an eye out on the Updates announcement (date change in the title) for a newer version.

I don't have any way of testing changes to GFdisplay here, so I will have to rely on your feedback.

Regards

Pete

Link to comment
Share on other sites

Keep an eye out on the Updates announcement (date change in the title) for a newer version.

Actually, there were more changes than I expected -- the MCP Pro has a lot more LEDs than anything else, and of course 6 digital displays compared with the MCP's 5. I've also added the single digit for the GF-ATC.

Because of all these changes, and the fact that i don't know whether the digital displays are still numbered left to right, as in the MCP, I can't release the update till some testing has been done for me.

So, the update is a Beta, 1.241, and is attached. Please do try every LED and every display, and tell me what goes on.

Thanks.

Pete

GFdisplay1241.zip

Link to comment
Share on other sites

Hi Pete,

Progress so far:

1) The MCP Pro is recognised and a GF connections entry is added.

2) Displays are mapped as follows:

0 = Left Hand COURSE

1 = IAS/MACH

2 = HEADING

3 = ALTITUDE

4 = VERT SPEED

5 = Right Hand COURSE

3) Lights are mapped as follows:

0 = VNAV

1 = LNAV

2 = CMD A

3 = CMD B

4 = A/T Arm

7 = VOR LOC

9 = CWS A

10 = CWS B

14 = Flight Director Left

15 = N1

16 = SPEED

17 = LVL CHG

18 = HDG SEL

19 = APP

20 = ALT HOLD

21 = V/S

4) Problems with the displays:

-V/S shows divided by 10 and go's to zero at -8900 or lower and at 8800 or higher

-Altitude shows divided by 10

5) Problems with the lights:

- Cannot find the light value to light the right hand Flight Director light. Have tested for faulty LED and its fine. Have tested upto light value L130 and I still cannot find it - any advice?

- Only the last light stays on. They all work, but when a new light gets displayed, the previous ones lit go's out. For example with the AP and FD on in the sim I start GFDisplay and the lights are on OK. Hit any of the AP buttons e.g. APP and the lights go out. Turn off and on the FD and then the APP light will go out. It seems to be only able to sustain one light command at a time.

6) Here is the config I've been using:

[GFMCPPRO.0]

Needs=V16 B E A

B=4 ; No too bright?

D0.1=C5 XC4E U16 D30 ;NAV1 CRS as nnn

D0.2=!C5 "360"

D1.1=C0 C47 "" ; PM blank VS

D1.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's V/S as (-)nnnn

D1.3=!C0 X7F2 S16 D-40 ; FS's V/S as (-)nnnn

D2.1=C0 C6 X4E2 U16 D30 ; PM's HDG as nnn

D2.2=C0 !C6 "360"

D2.3=!C0 C7 X7CC U16 *360 /65536 D30 ;FS's HDG as nnn

D2.4=!C0 !C7 "360"

D3.1=C0 X4E4 S16 *100 D-50 ; PMs Alt as (-)nnnnn

D3.2=!C0 X7D4 S32 *3.28084 /65536 D-50 ; FSs Alt as (-)nnnnn

D4.1=C0 C47 "" ; PM blank VS

D4.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's V/S as (-)nnnn

D4.3=!C0 X7F2 S16 D-40; FS's V/S as (-)nnnn

D5.1=C5 XC4E U16 D30 ;NAV1 CRS as nnn

D5.2=!C5 "360"

L2.1=C0 X4F0 U16 M0001 ; PMs AP Master 1

L2.2=!C0 X7BC U32 ; FS's ap eng

L3.1=C0 X4F0 U16 M0001 ; PMs AP Master 1

L3.2=!C0 X7BC U32 ; FS's ap eng

L4.1=!C0 X810 U32 ; FS's Auto Throttle Active

L7.1=C0 X4F0 U16 M0020 ; PMs LOC -> NAV light

L7.2=!C0 C8 X7C4 U32 ; FS's NAV acquired

L7.3=!C0 !C8 X7C4 U32 Fslow ; FS's NAV (flash)

L14.1=!C0 X2EE0 U32 ; FS's Flight Director Active

L16.1=C0 X4F0 U16 M0200 ; PMs Speed

L16.2=!C0 !C2 X7DC U32 ; FS's IAS -> SPD

L16.3=!C0 X7E4 U32 ; FS's Mach -> SPD

L18.1=C0 X4F0 U16 M0080 ; PMs HDG

L18.2=!C0 X7C8 U32 ; FS's HDG

L19.1=C0 X4F0 U16 M0010 ; PMs APP

L19.2=!C0 C4 X800 U32 ; FS's APP LOCKED

L19.3=!C0 !C4 X800 U32 Fslow ; FS's APP Pending (flash)

L20.1=C0 X4F0 U16 M0008 ; PMs ALT

L20.2=!C0 X7D0 U32 ; FS's ALT

Best wishes

Steve

Link to comment
Share on other sites

-V/S shows divided by 10 and go's to zero at -8900 or lower and at 8800 or higher

-Altitude shows divided by 10

The limits on the V/S might be correct. I'll check though. I've not even got an MCP non-Pro to test on these days.

Not sure why they should be divided by 10, as I'm using the same code as for the non-Pro model. How many digits do the displays have?

- Cannot find the light value to light the right hand Flight Director light. Have tested for faulty LED and its fine. Have tested upto light value L130 and I still cannot find it - any advice?

L130? The numbers only go up to 31 max in any case. I suspect the right FD LED is #23 -- it is marked in the GoFlight SDK doc I have as not connected, though. I'll try enabling it for you.

- Only the last light stays on. They all work, but when a new light gets displayed, the previous ones lit go's out. For example with the AP and FD on in the sim I start GFDisplay and the lights are on OK. Hit any of the AP buttons e.g. APP and the lights go out. Turn off and on the FD and then the APP light will go out. It seems to be only able to sustain one light command at a time.

Hmm. That implies that the facility to read the lights isn't working, which is a worry. It works okay on all the other units. If GFdisplay is the only thing using the displays then I could do it by remembering the last value written, but generally GFDisplay is designed to be able to share functions with the GoFlight software, or even with other copies of GFDisplay on other WideFS client PCs.

D1.3=!C0 X7F2 S16 D-40 ; FS's V/S as (-)nnnn

D3.2=!C0 X7D4 S32 *3.28084 /65536 D-50 ; FSs Alt as (-)nnnnn

I don't remember much of this stuff, but those lines seem to imply that the ALT display has 5 digits plus sign, and the V/S has 4 plus sign. Can you confirm exactly how many digits there are please? I might be mis-viewing the photos on their website.

Regards

Pete

Link to comment
Share on other sites

Hi Pete,

I have just tested the VS with the GF Data Bridge and it display upto +/- 9900. The VS has 5 digits. Using GF display -700 is shown as -070 and an altitude of 3000 is shown as 0300. The GF Data Bridge would show them -0700 and 03000 respectively.

Just doubled checked light 23 and it won't turn on so if you can connect it that would be great.

I have just simplified the config so only the lights for just the FD and AP are monitored. If the FD is turned off or on the AP light goes out even though FS-Interrogate and the sim shows it as on. Same with the FD. The lights are cancelled when another is turned on.

The Altitude has 5 digits as does the speed and VS.

Thanks

Steve

Link to comment
Share on other sites

I have just tested the VS with the GF Data Bridge and it display upto +/- 9900. The VS has 5 digits. Using GF display -700 is shown as -070 and an altitude of 3000 is shown as 0300. The GF Data Bridge would show them -0700 and 03000 respectively.

Okay, thanks. Useful info.

Just doubled checked light 23 and it won't turn on so if you can connect it that would be great.

Yes. I actively disable LED numbers which GF says aren't connected. They probably wouldn't do any harm, but you never know! ;-)

The lights are cancelled when another is turned on.

Yes, I understood the first time. I'll re-check my code, but if that is okay I'll need to do it the less friendly way, assuming GFdisplay owns the LEDs exclusively.

Regards

Pete

Link to comment
Share on other sites

To clarify on the HDG and CRS. Its not the change from 359 to 360/000. It will not display the digit 9 in any position. So 359 becomes 350. 298 becomes 208. Very strange.

So, for instance. you get sequences like 298, 299, 300looking like 208, 200, 300?

The routines to display the numbers are the same for every display, so can you please check the 9's on the others -- the speed, altitude and V/S?

Pete

Link to comment
Share on other sites

Yep, you are correct. No 9's appear on altitude, VS and speed either.

I've just checked my GF166A and its displaying 9's fine with GFDisplay.

It looks like Go Flight changed everything with the MCP Pro. Deep Joy! :(

Have you definitely checked that they display the 9's correctly with GF's own software? If not then it sounds like a hardware fault. Ah, wait a minute -- didn't you say that the GF software got to +/- 9900 on the V/S?

If it isn't hardware I can only think there's something wrong in the interface module, GFDev.DLL. Either that or they've done something mighty strange with the code I have to send for '9's, which seems very unlikely. Could you please try the slightly older GFDev.dll from my Updates announcement just in case they've messed something up in the newer version?

The setting of these LED segments is simply by bits in a byte. Examples:

The digit 0 is 3F (0011 1111)

The digit 8 is 7F (0111 1111) .. one extra bit for the crossbar

The digit 9 is 6F (0110 1111) .. like an 8 but losing a left-hand element.

To get 9's changing to 0's would mean two bits being changed. Very strange.

Let me summarise the problems:

1. LED missing, probably L23

-- easy for me to fix, and I will

2. Vis goes to +8800 and -8900 (care to amend that last, since 9's don't appear?).

-- I've checked. I do not impose any limits -- that would be up to your parameters. Would the changing of 9's to 0's maybe misleading you there? 9900 -> 0000?

For now I'll assume this is a 9's problem.

3. V/S and ALT divided by 10.

-- This is a real mystery. Both of these were 5 digits displays on the non-Pro MCP and worked fine. I do have one possible qualm, with the altitude:

D3.1=C0 X4E4 S16 *100 D-50 ; PMs Alt as (-)nnnnn

D3.2=!C0 X7D4 S32 *3.28084 /65536 D-50 ; FSs Alt as (-)nnnnn

These both require the Altitude display to be capable of 5 digits plus a sign -- which, unusually the non-Pro one was. Could, possibly, the MCPPro one not have this capability? If so then you might be simply losing a digit for a sign. (Real MCPs do not show negative Altitudes BTW, 00000 is the minimum). So try D50 instead of D-50 here.

That wouldn't explain the V/S losing a digit though.

4. LEDs not being read (so only getting 1 set at a time)

-- I think this is certainly a bug in GFDev.dll. The code is definitely correct here. It seems that the facility to read the state of the LEDs is not working.

I can program around this, by remembering what has been set before. But this goes against the grain a bit -- I've always made GFdisplay cooperate with other programs using the same hardware.

5. The 9's changing to 0's everywhere (!)

-- That's a real b****r. I can't see an easy way around that. It must surely be a bug in GFDev.dll, but i can't imagine what sort of bug could do that. If it was my segment tables (the ones for digits 0-9, A-Z, as per the examples above) getting corrupted it would affect 9's everywhere, on every device.

There is another way of writing to displays, using plain text strings instead of lighting the segments up specifically. I could try that, just as an experiment. But I've never used them before so I'm not really sure how they work. I can guess though.

Regards

Pete

Link to comment
Share on other sites

There is another way of writing to displays, using plain text strings instead of lighting the segments up specifically. I could try that, just as an experiment. But I've never used them before so I'm not really sure how they work. I can guess though.

Okay. Please try the attached version 1.242. I've made these changes only:

1. Allows LED23.

2. Keeps its own record of LEDs set, not trusting the read facility.

3. Uses the alternative text display mode for the displays -- on the MCPPro only.

Let me know what results this gives.

I've also posted some questions off to GoFlight themselves.

Regards

Pete

GFdisplay1242.zip

Link to comment
Share on other sites

Hi Pete,

The GF data bridge displays nine's OK in all displays.

I have just replaced the GFDev.dll file in the modules directory with your version and it didn't change anything. Note I made sure the data bridge did not autoload so no other GFDev could have loaded. I run GFdisplay from the modules directory.

Regarding number 2. Yes that was a typo by me it should have read -8800 and yes it is to do with the number 9 not displaying correctly.

Regarding number 3. I had already tried that, but have double checked and it makes no difference. The sign is dropped, but only 4 digits display and its divided by 10.

Best wishes

Steve

Link to comment
Share on other sites

Just need to sort this number 9 and division by 10 problem and were smokin! :wink:

Sorry, I'm not clear what you mean. Are you saying that the displays are still wrong, even using a completely different call into GFDev.dll? I'm not dealing with segments now, just sending the text to the device using text requests. Is there no difference at all?

I'm amazed.

Do the displays actually display text if sent, e.g. like "TEXT"?

Regards

Pete

Link to comment
Share on other sites

Sorry pete, the 9's do display correctly now as well. I hadn't realised you had changed that so didn't check.

The division by 10 is still present. I have found a work around by using the D parameters fractional part. E.g.

A VS of -9900:

D-50 = -0990

D50 or D5 = 0990

D40 or D4 = 990

D-41 = -9900. (the last "0." represents the 1 digit fractional part and yes the "." does display. Its a work around I guess)

Thanks

Steve

Link to comment
Share on other sites

Sorry pete, the 9's do display correctly now as well. I hadn't realised you had changed that so didn't check.

Uh. :-( I did list it in the list of 3 changes.

The division by 10 is still present. I have found a work around by using the D parameters fractional part. E.g.

Hmm. Why not just multiply the value by 10?

I missed one of your replies which included this: "but only 4 digits display and its divided by 10". That implies that the digit missing is a 6th digit which I don't send. That's interesting. It implies a different interface despite the similarity to the MCP non-Pro.

I'll make a version with 6 characters being sent.

[LATER]

Ahbefore I do that, please confirm that the Speed display is okay. That's another supposedly 5 digit display, right? So it should suffer the same digit loss?

Regards

Pete

Link to comment
Share on other sites

Sorry I missed it.

The multiplication by 10 works for VS and IAS but not altitude since some multiplication and division is already there. I tried to bracket off the equation and *10 afterwards but it looks like the bracketing is ignored. You just end up with a bizare number.

Yes, the IAS does suffer from the digit loss.

Thanks

Steve

Link to comment
Share on other sites

This is the config that's working with the fudges on IAS, Altitude and VS

[GFMCPPRO.0]

Needs=V16 B E A

B=10 ; No too bright?

D0.1=C5 XC4E U16 D30 ;NAV1 CRS as nnn

D0.2=!C5 "360"

D1.1=C0 C48 "" ; PM blank Spd

D1.2=C0 !C48 C1 X4E8 U16 /100 D02 ; PM's Mach as (n).nn

D1.3=C0 !C48 !C1 X4E0 U16 D30 ; PM's IAS as nnn

D1.4=!C0 C46 X7E8 U32 /65536 D02 ; FS's Mach as (n).nn

D1.5=!C0 !C46 X7E2 *10 U16 D30 ; FS's IAS as nnn

D2.1=C0 C6 X4E2 U16 D30 ; PM's HDG as nnn

D2.2=C0 !C6 "360"

D2.3=!C0 C7 X7CC U16 *360 /65536 D30 ;FS's HDG as nnn

D2.4=!C0 !C7 "360"

D3.1=C0 X4E4 S16 *100 D-50 ; PMs Alt as (-)nnnnn

D3.2=!C0 X7D4 S32 *3.28084 /65536 D41 ; FSs Alt as (-)nnnnn

D4.1=C0 C47 "" ; PM blank VS

D4.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's V/S as (-)nnnn

D4.3=!C0 X7F2 S16 *10 D-40; FS's V/S as (-)nnnn

D5.1=C5 XC4E U16 D30 ;NAV1 CRS as nnn

D5.2=!C5 "360"

L2.1=C0 X4F0 U16 M0001 ; PMs AP Master 1

L2.2=!C0 X7BC U32 ; FS's ap eng

L3.1=C0 X4F0 U16 M0001 ; PMs AP Master 1

L3.2=!C0 X7BC U32 ; FS's ap eng

L4.1=!C0 X810 U32 ; FS's Auto Throttle Active

L7.1=C0 X4F0 U16 M0020 ; PMs LOC -> NAV light

L7.2=!C0 C8 X7C4 U32 ; FS's NAV acquired

L7.3=!C0 !C8 X7C4 U32 Fslow ; FS's NAV (flash)

L14.1=!C0 X2EE0 U32 ; FS's Flight Director Active

L16.1=C0 X4F0 U16 M0200 ; PMs Speed

L16.2=!C0 !C2 X7DC U32 ; FS's IAS -> SPD

L16.3=!C0 X7E4 U32 ; FS's Mach -> SPD

L18.1=C0 X4F0 U16 M0080 ; PMs HDG

L18.2=!C0 X7C8 U32 ; FS's HDG

L19.1=C0 X4F0 U16 M0010 ; PMs APP

L19.2=!C0 C4 X800 U32 ; FS's APP LOCKED

L19.3=!C0 !C4 X800 U32 Fslow ; FS's APP Pending (flash)

L20.1=C0 X4F0 U16 M0008 ; PMs ALT

L20.2=!C0 X7D0 U32 ; FS's ALT

L23.1=!C0 X2EE0 U32 ; FS's Flight Director Active

Link to comment
Share on other sites

The multiplication by 10 works for VS and IAS but not altitude since some multiplication and division is already there. I tried to bracket off the equation and *10 afterwards but it looks like the bracketing is ignored. You just end up with a bizare number.

Er, if it is subjected to *3.28084 /65536, just change that to *32.8084 / 65536. It's simple arithmetic! Something which is 10 times bigger is ten times bigger, isn't it?

In fact the examples in the doc are only expressed like that as an "example". Obviously you could replace the *3.28084 / 65536 by * 0.000050061646 or by /19975.372, both of which change the original value by the same factor. If you don't understand why, just get a calculator out and do the division yourself, either way up.

Yes, the IAS does suffer from the digit loss.

Ah, good job you said that. I was just about to give you an update assuming otherwise.

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.