Pete Dowson

In that case the "Mouse button up" controls I've added won't do any good. Sorry. Well it is always sensible to keep a backup of your INI file, but, no, FSUIPC won't change anything simply because you updated it, except possibly adding new parameters where stuff has been added. Yes, that's why I suggested calling the new file 2test" or something, so you could delete it afterwards. You should delete all the duplicates. You only want one of each -- and since "APU Norm" doesn't work you might as well delete all of that. Well, what would be simplest and quickest to load would be this, instead of all the above: 21=APU Start=RX70280*X8bcc 22=APU Norm=RX70280*X8bcc 23=APU Off=RX70310*X8bcc except, as i say, you might as well omit the non-working line 22. Don't you think it might be worth while getting in touch with the aircraft developers, to see if they have any suggestions for a solution to the APU Starter return when not using a mouse? You never know. Regards Pete

I've had just a brief glance at the code. I'm no VB programmer, but it looks to me as if you are using a different signature each time. Why? To FSUIPC this makes you look like a different program, and it will lock you out for the timeout (14 secs) on the previous request. The TXT file about the NWI does explain this -- you should use your own unique signature to prevent others messing you up, but the SAME ONE for each request, or Zero if you don't care about others getting their weather (as for instance my own WeatherSet using zero). You are also apparently checking the signature as your "handshake". Is that right? Why? Where do you get that from? As is clearly documented, the handshake back to you is a change of timestamp. You watch for that then check that the ICAO is the one you wanted. If not, it failed. Please do read what is written in more detail. I can answer questions if you like. It would certainly be a lot easier than posting code to be looked at. And please do use the FSUIPC logging, which would show all this stuff in no time. Pete

It certainly sounds like you have something wrong there. No, not at all. There have been several weather radars based on the interface. It have been around for quite a few years. I myself use SA-WXR in my cockpit for weather radar on my Project Magenta ND, and the same author sells a gauge using it. Maybe you have the handshaking wrong? Have you bothered t use the FSUIPC logging facilities, specifically provided to help you resolve this sort of thing? Not FSUIPC logs though. don't you like using FSUIPC facilities to help? I don't understand. I would have thought that would be your first port of call. Regards Pete

In FSUIPC4 (for FSX) you can assign it in the Axis assignments Tab to "Pan view". That should give you the same facility as the normal FSX assignment. Maybe not quite as smooth (FS doesn't have to use SimConnect), but pretty good. Sorry, but in FSUIPC3 (for FS2004) this method isn't available. Regards Pete

I've compared my code for Flaps in FSUIPC4 and FSUIPC3, and I can apply the changes I made in FSUIPC4 to FSUIPC3 too. Maybe these will be okay. I'll have to re-check on the defaults. I may have an update for you to try over the weekend. Regards Pete

You haven't run the Installer then. You cannot merely copy FSUIPC4.DLL into FSX and expect it to work! It is not like any previous FS version! Please download the full FSUIPC4 package from the Schiratti site and read the installation instructions. Regards Pete

Can you do the same things for me, then, as John did. i.e. on the Logging tab in FSUIPC, right-hand side: Monitor 0BDC as U16 for the flaps control, 0BE0 and 0BE4 for left and right flaps indicators, also U16. Set this to display in the FS (Advdisplay) window and in the Normal log you can see them in real time. Note down the values you get showing for each flap detente. It is very difficult to make sets of values to suit all add-ons. The formula I originally used was related to how FS itself interprets the values, and works for all defaults. However, those add-ons like PMDG, which implement their own flap operations, seem to have chosen different ranges. The only way I can make them work on all is to try to choose points which fall in the correct ranges in both, which is actually quite difficult in the the two outside detentes for PMDG. Regards Pete

Why use RAW? Really that facility, whilst intended for uses with EPIC, is actually suited to SOFTWARE axes, i.e. those axes controlled by the programming of the EPIC rather than merely the A to D converters for axes connected there. And then you wouldn't be sending the values "for calibration" as they would be for use as they are, real numbers for things like Headings, Altitudes, etc. By "same throttle position" do you mean exactly the same, or you mean roughly by feel or look? When you move the throttle, is the IN value moving in the high range, or is this 17800 value you see just the initial one, there when you open the Tab? That doesn't sound like the same thing at all - the neutral position would be a value which calibrates to zero, so not an extreme, larger, value but something near your 128 (for the 0-255 range). Sorry, I have no idea about that. Do you get no problem when you don't have it mapped to 4 throttles? My first inclination would be to change from RAW mode and use the normal input mode which is quite correct for analogue axes and suits them better. RAW mode is supported for passing usable numbers, not intended to be calibrated. However, I'd like to get to the bottom of this problem even if that would be the best thing (and quickest thing) to do. Obviously i need more information. Can you use the Logging facilities in FSUIPC, please? The Axis logging check box should be set. You will get HUGE logs, and I don't want to wade through them, so I'd need you to try to narrow them down to the area getting a problem. If you have to send me anything, ZIP it, please, and send to petedowson@btconnect.com. Oh, and please first update to the latest interim version, from the Updates announcement above, just in case something I've changed in the last two months affects it. Regards Pete

If it says it is an invalid registration then you are making a mistake! All three parts -- name, email address, and Key must be EXACTLY as you used when purchasing it and confirmed in your receipt. Use copy and paste if you can't enter correctly ort are not sure. If you had saved the FSUIPC4.KEY file, as advised in the documentation, then you'd only have to copy that back into the Modules folder after reinstalling FSX. You only have to re-enter the registration after a Windows re-install or changing PCs. Pete

Ugh. Most SimConnect problems appear to arise that way. I'm beginning to believe that folks might as well re-install Windows if they're going to reinstall FSx! :-( Well, that's good so far. MTX? What's that? I'd need to see both the Install and normal Log files, from the FSX Modules folder, to hazard a guess. Al the information will be there. Regards Pete

You need to use the runway centre Lat/Lon, its true heading, and its width and length to compute the Lat/Lon coordinates of the four corners, then see if the aircraft position lies within them. It is mostly simple arithmetic and a little simple trigonometry. Draw yourself a little diagram and you'll see how to work it out. Sorry, I really haven't got time to work it all out for you. If you are really stuck maybe someone will jump it, but otherwise, for general programming questions like this, you might get more detailed answers posting on one of the programming-oriented forums, maybe over at Avsim? Regards Pete

Version 3.75 is very old now (over 18 months, and almost as many versions), and is not supported. The earliest supported version is 3.85, and there are later updates supplied in this Forum, in the Announcements above. Please ensure you are using a supported version before asking for support. I really cannot deal with outdated versions. If you are not sure, please read the relevant Announcements in this Forum before posting. Regards Pete

These are the important lines: and as you can see, the mouse operation, whatever you did for "APU Norm", is exactly the same as the one for "APU Start". I was hoping that either there was some difference, or more likely a different Mouse mode shown (this would be indicated by ",n" with some number n, after the "RX ....X8bcc" part. So, I'm sorry, but I don't think I can do much for this. You haven't replied about the left mouse button being released elsewhere, so I either assume you tried it to no avail or you still don't understand what I'm getting at. But never mind. Just in case it might work (and it's a very slim chance), I have added "Mouse button 1 up" and "Mouse button 2 Up" controls which you can assign. These are in the latest FSUIPC updates available from the Updates Announcement above. Regards Pete

Such a "toggle" is in use in many hardware cockpits. The Autothrottle Arm control IS a toggling control. Use that to arm and dis-arm. Haven't you even tried it yet? If you are unsure about what controls do what, but know how to do it on the FS panel, just enable the Event logging in FSUIPC (logging tab), operate the control, and look in the FSUIPC Log file (in the modules folder). You will see the name and number of the control, and any parameter value it used. Pete

Not at present there isn't. I'll take a look. If it is easy enough to do, I'll add it as another [buttons] parameter. Pete

Ah. I hadn't spotted that one, or thought it not the relevant one. I'll see if that works. Okay, I think everything is now okay, 0898 and 08F0, if you could double check for me -- FSUIPC version 4.424, now available in the Updates announcement. Thanks, Pete

I am pretty sure the issue is fixed in FSUIPC 3.864 and FSUIPC 4.424, both now available in the Updates announcement above. Regards Pete

Yes, I'm okay, thanks, except for the eye problems getting worse month by month now, not even year by year. But that was more or less expected with this Retinitis Pigmentosa condition. Are you still flying all over the place, or have you settled into software/hardware development full time now? Regards Pete

Yes, all the default panel types have names. Here's an almost complete list: MAIN_PANEL 0 MAIN_PANEL_ALT1 1 MAIN_PANEL_ALT2 2 MAIN_PANEL_ALT3 3 MAIN_PANEL_ALT4 4 MAIN_PANEL_ALT5 5 MAIN_PANEL_ALT6 6 MAIN_PANEL_ALT7 7 MAIN_PANEL_ALT8 8 MAIN_PANEL_ALT9 9 THROTTLE_PANEL 10 RADIO_STACK_PANEL 50 COMPASS_PANEL 75 MINI_CONTROLS_PANEL 100 ANNUNCIATOR_PANEL 125 ANNUNCIATOR2_PANEL 150 IFR_MAIN_PANEL 175 COLLECTIVE_PANEL 200 GPS_PANEL 225 OVERHEAD_PANEL 250 PARKING_BRAKE_PANEL 251 FLAPS_TRIM_PANEL 252 FUEL_PANEL 253 ELECTRICAL_PANEL 254 TRIM_PANEL 255 LANDING_GEAR_PANEL 256 MISC_POPUP_1 260 MISC_POPUP_2 261 MISC_POPUP_3 262 MISC_POPUP_4 263 MISC_POPUP_5 264 MISC_POPUP_6 265 MISC_POPUP_7 266 MISC_POPUP_8 267 MISC_POPUP_9 268 MISC_POPUP_10 269 Alternatively, when the panels aren't selectable using the Shift 1-9 (PANEL_1 to 9) controls, there's usually an icon some place on screen to toggle them. If you enable "Event" logging in FSUIPC's options, then click the icon which operates the panel, you'll see the data logged. For the standard GPS_PANEL control it looks like this: 292078 *** EVENT: Cntrl= 66506 (0x000103ca), Param= 225 (0x000000e1) PANEL_ID_TOGGLE The parameter gives the ID, 225 in the case of GPS_PANEL, confirming the value for it in the list. Pete

That's what I thought, and was waiting for the Log to confirm. but I'd also need to see the log to see if there's anything I can do to help. It seems to be forever coming! ;-) No no no no! JUST do the things I ask. Enable button logging. That's it. Then OK out. I've said exactly this several times now! It's so damned easy. If in any doubt why not read what I write? Or even look in the user documentation supplied with FSUIPC? :-( Did you try the mouse thing yet at all? Pete

Yes, of course. That's the button which when released on the switch releases it from Start, right? Not the centre button or the right button? This is why I said (3rd time now?) "with the mouse far away from the switch, preferably somewhere innocuous like in the outside view, click and release the left button.". See? Mouse was the operative word there? I am trying to see if me sending a Mouse Button Up message might work. I thought I said that way back? No not nearly, really, but it shouldn't have mattered: As I asked, just enable "button and key logging" -- then and click OK as usual to get out. Nothing else. Why start a new log? Anyway, the log renamed FSUIPC.1.log is the OLD log, the NEW log, with the button logging in it, will be FSUIPC.log as always. Each time you start a new log it will keep the old one like that. But there's no need at all unless you want a proliferation of files! The "display to normal log" checkbox in on the Monitor side of the logging tab and is completely and utterly irrelevant unless you are entering offsets in the table there for monitoring. Why not just check the things I say? Or peruse the user documentation. There's a section on each Tab. Anyway, another day now. It's late here (02:35 am) and I'm off to bed. Looks like this may take a few weeks! ;-) Regards Pete

If it isn't huge you could just paste it into a message. If you put it in as "Code" it will be in a scrollable section of its own, if big enough. Otherwise you can email it, ZIPped please, as an attachment, to petedowson@btconnect.com. Hmm. Interesting, but not really useful for me as I'm not using the mouse itself. What I suggested trying was, to repeat with emboldening: "Use the button to set the APU to start, then, with the mouse far away from the switch, preferably somewhere innocuous like in the outside view, click and release the left button. See if the starter releases." Sorry, it may have been ambiguous. If the switch release only works by the gauge using mouse capture, then there's no way I'm going to be able to do anything with it. We'll see. I suppose you can't get any help from the aircraft makers themselves? Maybe they've used unpublished tricks in FS and want to keep them quiet for competitive reasons, but on the other hand it may just be something I've missed! Regards Pete

By changing the PollInterval, an optional parameter for the main [buttons] section, as described in the Button Programming section of the Advanced Users Guide. The default has been arrived at over many years, so shouldn't be changed on a whim, but by all means experiment if you must. Hmm. Odd.You should be able to do it singly quite easily. Are the button signals from the device getting delayed? Won't decreasing the refresh from the device make things worse rather than better? You want the button release signal to get to FS/FSUIPC as soon as possible, not delayed by another 100 mSecs (for 10 Hz). Maybe the slowish refresh rate of 50Hz at the device is the main cause of the problem. Add to that the potential delays through Windows and the queueing system. I think the default poll interval in FSUIPC is 25 mSecs, so if the delay of the release is often at least 20 mSecs (from the 50Hz rate) I can see there being occasions when at least one repeat would occur. If FS is very busy, more maybe. Have you tried increasing the device's poll rate? Of course if the MFP has buttons-a-plenty, or a "shift" arrangement for doubling them, you could assign two different buttons, one fast and the other slow. Incidentally, what FS control are you assigning to for this? Sometimes FS accelerates these as well, as when, for instance, it receives two or more controls of the same type within a certain time. That might be responsible for some of it too. Regards Pete

Thanks. I see you are using Aircraft specific settings, not "Profiles". It looks like FSUIPC is not, initially at least, overriding the generic key assignments (in [Keys]) for those keypresses which have aircraft-specific settings. The double assignments I see (there may be more) between the [Keys] section and the [Keys.PMDG747-400] section, occur for these Keypresses: 72,11 90,11 97,8 98,8 99,8 100,8 101,8 102,8 103,8 104,8 105,8 189,10 I suspect it is these double assignments giving you the problems you describe -- looking at them some do seem to be combinations like, for example, 97,8 operating both PANEL 1 and Panel ID toggle 30. I'll look at this and fix it as soon as I can -- it must be related to the changes I've added recently, maybe those for Profiles. I'll check those too. Strange how it corrects itself on reload -- there's obviously some parameter or flag I'm not initialising properly on first load. I don't know how long it'll take me to fix this, maybe a day or two. If you are mostly using only the PMDG747 then you could continue okay by temporarily disabling the [Keys] section (e.g. by renaming it [xKeys]). Regards Pete

How strange. I'll need to see the FSUIPC logging for that, with button & keys logging enabled. It certainly sounds like you have the same key programmed twice, or even once by still for keyboard. Maybe you should also post the all the [Keys...] sections from your FSUIPC4.INI file. Then I can see what you have done. No idea. I wouldn't have thought so -- they are used for two functions by FS itself, depending on NUMlock (views and flight controls). I think you still have the olde key-ress assignments in your configuration, you've not deleted them, only added more, so things are getting into a mess. It just says please wait whilst settings are being loaded. I added that because some folks have large complex sets of settings and, what with the Profile lookups and JoyName matchings, it is starting to take enough time that it can look stuck. All that using the reload buttons does is repeat what FSUIPC would have done when first loaded. Certainly, it wil revise profile listings, so if there's something tangled up in your INI file it could get into a mess still. Maybe you sohlud actually ZIP your FSUIPC4.INI file and send it to me at petedowson@btconnect.com. It sounds like you've got into a bit of a mess. Logging options "stick", so if you enabled the Button and Key logging and closed FSX down, the logging would stil be there next time. Regards Pete