John Dowson

Looking at that ini, there is no axis assigned to throttle1: ?

This seems rather strange, as you are sending the left/right brake controls on the R (rudder) axis, and are also repeatedly sending BRAKES_RIGHT or BRAKES_LEFT when the rudder is more than approx 2/3rds full left or full right.

I am not sure I understand this - and I don't have this aircraft. Do you have a reference on how this works or can you provide further details? How is the "brake handle" recognised - is that an axis or button, and is any control logged when used, or maybe an lvar is changed? You will probably need to use lua if you want an axis condition. You would write the axis values to an FSUIPC offset, and have a lua script monitor these offsets, calibrate the value and send the appropriate control depending on the brake handle position, which would also need to be monitored. There is a User Contribution for something similar, where a brake lever is used to control differential braking on a rudder axis - not the same I know, but shows the technique of how to send different controls on an axis depending on another lever: I can see if I can get hold of this aircraft and take a look, but this may take a while. John

Can you please make sure you are using the latest released version of FSUIPC7, 7.4.11, or even better try the latest beta release, available from: and show me your FSUIPC7.log, FSUIPC7.ini and csv files. As I said, I only see this here when FSUIPC7 is started by MSFS via the EXE.xml file, and I have no idea why this is. I will look at you files to see if I can see anything, but there is not much I can do. What is the load like on your system? What aircraft do you have loaded - if using an airliner, have you tried with a GA aircraft? John

Controls that go from external apps via SimConnect do not go through the same route as internal controls. This has already been raised with Asobo - see https://devsupport.flightsimulator.com/t/xml-key-event-bindings-do-not-intercept-key-events-via-simconnect/8320. I am not an aircraft developer/gauge programmer, so cannot really assist you with this xml code. Can you see the Input Event in FSUIPC (Log->List Input Events)? If so, you can use this directly. However, you can only assign to Input Events for buttons, keys and when entering/leaving axis ranges. To assign an axis to an Input Event in FSUIPC, you have to assign the axis to write to an FSUIPC offset, have a lua script that monitors the offset (using event.offset), calibrates the axis value to the Input Event range, and then send the Input Event using ipc.execInputEvent. It is also not clear to me how Asobo determine what Input Events are available via the SimConnect Input Event interface/functions. This would also be a question for Asobo. Sorry I can't be of more assistance - as I say, I am not a gauge programmer and you would get more help with this on the Asobo forums. John

The MF Hub-Hop resource/website is the community-driven effort for discovering and publishing presets. I am certainly not going to create a 'proprietary' set of presets - these should be available to the community. And from what I have seen of the C510, it seems to mainly use Input Events for a lot of external control. It is NOT possible to use input events via presets, which is why a presume there are no presets yet available on the MF Hub Hop site for this aircraft. This has been requested before and I have already spent quite a while looking into this. It turned out to be too problematic for several reasons, and I am not going to look at this again, at least for the time being. I am just too busy. I don't see a need. If you just want to know what input events are available, use Log->List Input Events. Just switch on Input Event logging when you want to see if an input event exists on a certain button/function, and to see what parameters it is using. No - there is no distinction between where key presses come from, I just get a key press/release events (not the source), so this is just not possible.

There will be no radar facilities available in the first release of AS for MSFS, but they are working on it. I will look into adding this to FSUIPC7 when available in AS. Regards, John

Pete is on holiday at the moment. I will ask him to take a look when he returns next week, but I doubt he will still have any technical information for this. I have no knowledge of CockpitSonic hardware and so cannot help, sorry. John

That is an A-var (a simvar) not an lvar. Why not just use offset 0x0BC8 (A:BRAKE PARKING POSITION)? I have added A:BRAKE PARKING INDICATOR in the attached version at offset 0x028D (1 byte). However, in the FBW A320 I do not see this offset change when I set the parking brake, but offset 0x0BC8 does. Are you sure the FBW A320 uses this simvar? John FSUIPC7.exe

Can you try the attached version please: FSUIPC7.exe

Unfortunately the title isn't yet available when I am reading the aircraft.cfg file, so this is not that straight-forward. I will see if I can read the aircraft.cfg file for this after the TITLE is received.

FSUIPC gets the title from the TITLE simvar. This may originate from the aircraft.cfg file, but it is not read from there by FSUIPC for exactly the same reason - it would not know which FLTSIM.x section to load it from. So I would need to check the title in the FLTSIM.x sections until I found one that matches the TITLE as received from the simvar, which is why I can only do this if this simvar is available BEFORE I read the aircraft.cfg file. All other data read from the aircraft.cfg file is read from the GENERAL section. It isn't that complicated, but I do need to check the order of things to see if this is possible. If the title isn't available in offset 0x3D00 by the time I read the aircraft.cfg file, then I will not be able to read the FLTSIM sections and will not add the icao_airline string (even if there is only one FLTSIM.0 section). I will check this and get back to you, but most probably tomorrow now. John

What am I looking for in that log - which button presses weren't working, and which were? I just cannot tell just from the log file. Please try with the logging console open (Log->Open Console), and let me know the timestamp of a button press not working, and also one where it is working. I see you have the flaps assigned to an axis using direct to FSUIPC calibration and calibrated in your PMDG 737 profile. This can cause issues with the climb rate - please see John

But how do I know what x is? Do you expect me to read the title in each FLTSIM section, and then read the icao_airline from the section that has a matching title? I could possibly do this, but I need to check if the TITLE simvar has been received by the time I read the aircraft.cfg fille - it may not yet be available. Of course, as it is currently only read from [FLTSIM.0]. Also, it seems that some strings are enclosed in double-quotes, others not. Will the icao_airline string always be enclosed in double-quotes, or can it also be without these? John

Yes, I saw that. So you want this read from the [FLTSIM.0] section? Other ICAO strings are read from the [General] section - e.g., for the C208: [GENERAL] atc_type = "TT:ATCCOM.ATC_NAME CESSNA.0.text" atc_model = "TT:ATCCOM.AC_MODEL C208.0.text" Category = "airplane" pilot = "Pilot_Female_Casual" copilot = "Pilot_Male_Casual" instructor = "Pilot_Male_Casual" performance = "Maximum Speed\n175 kts 324 km\/hr\n\nCruise Speed\n164 kts \t 305 km\/hr at 20,000 ft\n\nEngine\nPratt & Whitney Canada, Inc., PT6A-114A Free Turbine Flat Rated at 675 Shaft hp \n\nPropeller\nThree-Bladed, Constant Speed, Full Feathering, Reversible McCauley, 106-inch diameter\n\nMaximum Endurance\n5.1 hours maximum cruise at 10,000 ft\n6.6 hours maximum cruise at 18,000 ft\n6.4 hours maximum range at 10,000 ft\n7.2 hours maximum range at 18,000 ft\n\nService Ceiling\n22,800 ft 6,949 m\n\nFuel Capacity\n335 gal 1,268 L\n\nEmpty Weight\n4,575 lb 2,075 kg\n\nMaximum Gross Weight\n8,785 lb\t 3,985 kg\n\nUseful Load\n4,000 lb\t 1,814 kg\n\nLength\n41 ft, 7 in 12.7 m\n\nWingspan\n52 ft, 1 in\t 15.8 m\n\nHeight\n15 ft, 5-1\/2 in 4.8 m\n\nSeating\nUp to 14" icao_type_designator = "C208" icao_manufacturer = "CESSNA" icao_model = "208 Grand Caravan" icao_engine_type = "Turboprop/Turboshaft" icao_engine_count = 1 icao_WTC = "L" Please try the attached version where this is read from the [FLTSIM.0] section and added to offset 0x062C. Note that this will not be available if the location of the aircraft.cfg file is not available in offset 0x3C00 (possibly due to the aircraft being encrypted). I can switch to reading from the [General] section if needed, or possibly try both. Cheers, John FSUIPC7.exe

Do you know of an aircraft (preferably an Asobo/default one) that has this identifier? I have checked several and cannot see this. Looks like the ICAO airline is always 3 characters. I can add as a 4-character string (3 chars + 0 terminated, at offset 0x062C s this offset is no longer used in FSUIPC7.

That depends on whether AS for MSFS2020 provides an interface for this. I will contact HiFi to see what they are providing and what can be done. John

The fsuipc,com website is using the http protocol, not https. I will change this when I get time - its been on my todo list for a couple of years! Its not an issue though, you just have to accept the insecure connection, and all the downloadable files are on https anyway. As for the virus detected issue, this is a false-positive. See John

Sure, I can look into adding that. I will let you know when ready to test. John

It was probably due to the calibration - some aircraft don't play well with post calibration (i.e. calibrating the values received from the FS). Also see @Falcon49's post above if you want to use FSUIPC7 to control the rudder/ailieron for this aircraft. John

Finished for the day now and just about to eat... but try the attached ini where I have made a few minor adjustments (removed calibration for aileron and rudder for PC12, adjusted aircraft names in profiles). I will look further tomorrow. I think I know why DontLogThese isn't working as expected, but I will check further tomorrow. John FSUIPC7.ini

👍

No, it doesn't 'inject into a program'. Please see the various other posts on this subject. And please check for similar posts before creating a new topic. John

Have you assigned your yoke in MSFS then (or elsewhere)? If assigning in FSUIPC7, you have to remove the assignments in MSFS - I recommend you start with an empty profile for your device in MSFS if assigning in FSUIPC). And is this with your aileron still assigned in MSFS, assigned in FSUIPC, or in both? Then you either added it to the wrong place, or if you added to the aircraft profile section (where it should be added), then the aircraft you have loaded does not match the aircraft profile name. Can you please show me/attach both your FSUIPC7.log and FSUIPC7.ini file please - attach them, not post extracts.

FSUIPC7 is just logging what it sees (i.e. is received from MSFS). If FSUIPC7 is logging a key press, then it has received this from MSFS. If you haven't pressed the key, then something else must have sent it - key logging logs all key events received from MSFS. These can come from the keyboard or from a program that is sending keys to MSFS, including FSUIPC7. Anything sending keys should also a corresponding release for each key press. Logging of a key press/release looks like this (when the key is assigned in FSUIPC7): So the initial key down is received, then the repeats, until the key-up is received. The key I pressed was assigned with 'No repeats', so the assignment (to Input Event HANDLING_Yoke_Hider_1) was only executed on the initial key presses. The logging will look slightly different if the key is not assigned, and you will only see a few repeats (although I am not sure why without checking).