pseizinger

Thanks Pete, I understand. I wasn't looking for any additional support. I'm thinking that GFdisplay will work for some of the things that I was doing in MSFS (DME, various indicators and such) and you've done some great work in developing it - I appreciate that. I just thought you might find it interesting (and maybe useful) that your utility has applications outside of MSFS. Best Regards, Phil

Hi Pete, I did finally get around to testing GFdisplay with XPUIPC (I was in the middle of building a new computer for the simulator when I asked you and so I was unable to test until now). I thought you might be interested in knowing that GFdisplay does indeed work with XPUIPC both locally on the host computer and remotely on a client. However, X-Plane does not appear to recognize GoFlight modules as a joystick and so you cannot write to an offset to XPUIPC using the GoFlight controls. It appears for the moment that the only way to use the buttons and rotaries are with the GoFlight Plugin which limits how the modules can be configured. Also something a little strange, when one changes the aircraft on the host computer, the GoFlight displays which are directly attached go blank and you need to quit X-Plane and restart to get them to display again (using GFdisplay). That does not however appear to be the case for a client with GFdisplay - it countinues to display without issue. Best Regards, Phil

Hi Pete, I'm not sure whom I should ask this question, but since it concerns GF-Display I thought I would start with you. I'm setting up my simulator to run both FS2004 and X-Plane. There is a plug-in available for X-Plane called XPUIPC which is suppose to provide access to offsets in the same manner as FSUIPC. Since the offsets appear to be the same (middle marker = 0BAE in both plug-ins) and my understanding is that XPUIPC was written to allow some measure of compatibility for MSFS addons, I was wondering if you know if GF-Display would be compatible with XPUIPC? I have developed some rather elaborate displays using GoFlight hardware, FSUIPC and GF-Display and I would like to leveage this with X-Plane. Best Regards, Phil

I see some inherent problems in trying to get multiple pots to connect to the same axis. I have been looking at that issue as well and came to the conclusion that the pilot and co-pilot controls should be linked (I'm lucky in that regard as I was able to buy a complete set of Cessna rudder pedals complete with all of the linkages) mechanically and then in turn link the pedals to a single set of pots for control. That way I don't have to worry about input conflicts. Just a thought... Phil

Pete, The new version did the trick. Everything works like a charm! Thanks so very much! Best Regards, Phil

Pete, I will give a try this evening (after work) and report back on the results. Thanks for looking into this. Phil

Pete, I "forced" the displays on (I removed the conditional evaluations) for the 166s to verify that they work with the new version of GFDisplay and that they display the offsets correctly. This worked fine: the radio frequencies displayed correctly and the LED worked as well. For my test, I forced one of my 166s to display COM1 active and standby frequencies (I use the left and right buttons on the 166 to switch between COM1 and COM2 via FSUIPC). When COM1 is selected I can change the frequencies and swap the active and standy. When I select the COM2 button, none of the displays update when I attempt to change frequencies or try to swap active and standby. When I copy version 1.10 of GFDisplay back into the system, everything seems to work fine. So it would seem that the issue seems to be related to conditional evaluations for the displays. I am including a section of my INI file that includes the conditions and the subsequent evaluations. To keep things simple, I am only including the COM Radio section (the NAV is much more complicated). ; COM 10=X66C8 U16=0 ;Display COM1 11=X66C8 U16=1 ;Display COM2 [GF166.0] ; COM Radio Needs=E B A D0.1=C10 X034E R2 ;COM1 D0.2=C11 X3118 R2 ;COM2 D1.1=C10 X311A R2 ;COM1 sby D1.2=C11 X311C R2 ;COM2 sby L1.1=C10 1 ;Left LED lit for COM1 L2.1=C11 1 ;Right LED lit for COM2 Thanks for looking into this further. Phil

Well, I was hoping that the issue you addressed in this version would have fixed the minor problem that I was experiencing with the DME display in that the displays (Time to Station and Distance to Station) would not update as regular as they should the closer one got to the VOR (which if you are doing it correctly, you should be making smaller corrections). I guess I will go back to the ealier version and if I have some time, see if I can narrow down the issue with this newer version.

Pete, I have been using GFDisplay for (among other things) my GF-166 to display COM/NAV and DME information. I installed your newest version and now the neither the 7 segment displays or the LEDs on all of my GF-166s are working. I don't use a GF-45, but I have RP-45 units and the LEDs work normally. Nothing else changed in my configuration and when I install the previous version of the software the 166s work fine. Any thoughts? Best Regards, Phil

Sorry, but I'm not sure what you're asking. Are you looking for the list of offsets and their function?

The offset you are using is for the Pitot heat. Looks like you forgot the left bracket in the conditions area and you need an "=" for each light or display. I have made the changes below. [Conditions] 0=X029C U8 =1 ; [GFP8.1] Needs=B E B=8 L3=C0 For simple on/off conditions you could also use the following: [GFP8.1] Needs=B E B=8 L3=X029C U8 ;"ON" if non zero

Kevin, Asking GoFlight for help will most likely be a fruitless effort since it appears they are not responding to support requests in their fourm. That said, you need to provide a little more information as to what it is that you are trying to accomplish (i.e. what is the T8/P8 switch supposed to do when you flip/push it?). In a nutshell, if the switch changes a value in an offset somewhere in FS, then you set up a condition to test the offset that would equal a true or false (off or on) result and then configure the LED to light if the condition is true. It is a little confusing (I had to read the documentation several times to "get it"), however, the examples in the INI file helped a lot. Also, if you do a search in the GF forum for GFDisplay, you should find some good examples there that you can use. Phil

Pete, I have done some testing with the new offsets and overall they work pretty well. Something that I have noticed, however, is that the time to station does not seem to update unless there is a significant change in ground speed - if GS stays fairly constant, the time to station remains the same and does not update as you get closer to the station (I have verified this against the DME display in the radio stack and I have tested both offsets with the same result). If you pause the MSFS, the ground speed goes to zero and the time to station will update. If you unpause, the time to station will continue to update until ground speed becomes "stable" and then it will continue to display the same time and not update as you get closer to the station. The distance to station does seem to lag behind the DME display in the radio stack but only by a few seconds and overall I think that "it's close enough for government work". Ground speed seems to be just fine. One question I have is that I determined that there is enough digits on my GF166 to display ground speed and time to station in a single display. Is it possible to display these two offsets at the same time on the same display (i.e. D0)? Thanks, Phil

Initially I was thinking something like: D0= 0C29 / 0C2E * 60 (assuming I could get them converted to a numeric) But then I realized this wouldn't quite work since this would only give me the minutes and that a DME time to station is displayed as MM:SS. So then I was going to try and see if I could calculate the minutes and seconds and write the output to an offset (ala FSUIPC). To be honest, I haven't worked with GFDisplay ot FSUIPC for any length of time to know if this could even be done. However, I read in the FSUIPC documentation that certain offsets could be written to and so I figured that it was worth a go. I don't see anything within FSUIPC or GFDisplay that would allow me to convert text to numeric and such and so I never got that far in my testing. Phil

I am assuming (and maybe incorrectly) that I can calculate time to station as: Distance (NM) / GS (Kt/Hr) = Time to Station (in hours) * 60 = minutes to station If that won't work, then I'm back to my original question of would you be able to provide the time to station in an offset (with the format of MM:SS)? Thanks, Phil

Thanks Pete I am more than happy to test this for you. The trailing space shows up as a blank on the GF166 and moves the numbers indicating the speed or the distance over to the left by one LED (the distance actually moves over 3 LEDS since there is a two digit numeric that follows the space). As we are on the subject, the next step for me in "building" the DME will be to switch between a display showing speed/distance to station and a display showing speed/time to station. As speed and distance are character strings, it would be difficult to calculate time to station using these numbers (unless I could some how convert them to a numeric). Would it be possible for you to add a "time to station" offset as well? Thanks again Phil

Sure I can give you an example: 0C29 displays as "25.1 67" - the 25.1 is the actual distance and so I only want to display 25.1 or I guess to be more precise I want to format as NN.N only 0C2E displays as "106 " - and here I want to format as NNN only without the trailing space. I appreciate your help with this. Thanks, Phil

Hi Pete, I have been working with GFDisplay and have started out with some simple tasks, and to that end I have been successful. Now I am working on turning a GF166 into a DME (using 0C29 and 0C2E). I am able to display the speed and distance, however, there is a trailing space in the speed string and the distance string has a trainling space followed by two digits. I have looked through the documentation, but can find nothing that speaks (or hints at) being able to take effectively the first three characters of each offset. Could you provide some insight as to how I can accomplish this task please? Thanks Phil