John Dowson

That is 0x1530 or binary 0001 0101 0011 0000 in decimal... Yes. But it is far easier to ignore the binary and use hexadecimal as it is far more obvious. To convert BCD 0x1530 to a decimal equivalent (i.e. NOT the decimal value of the hex number), you drop the 0x and convert the string "1530" to the int value 1530, then divide by 100 to ger the decimal value 15.30, then add 100 (as the leading 1 is always dropped when frequencies are held in BCD format) to get 115.30. If you have the frequency in decimal, you cannot just convert that to hex - you do the same in reverse, i.e. subtract 100 to get 15.30, multiply by 100 to get 1530, convert to a string to get "1530", prepend 0x to get the string "0x1530", then you can convert that to an integer/hex number to get 5424/0x1530. But we are going in circles here...google can show you all you need to know about BCD format. You multiplied the lvar by 100, to get a lua number 10994.0. The writeSW funcrion would convert that to an C/C++ integer. No! The offset area is just a memory address range. You can read/write whatever type you like, including floats (4 bytes), doubles (8 bytes) and strings (any length). That is why there are ipc.writeDBL and ipc.writeFLT (and read equivalents), as well as the various offset logging types - see page 14 of the Advanced user guide to see the types supported. Some simvars that are floats are converted and stored as integers, but this is for historical reasons. The offset documentation should say if any conversion is necessary - although it doesn't specify the type (only the size). Usually the type is obvious, but in some cases not, when you should refer to the FS documentation for clarity. I will update the offset documentation to specify the actual type at some point... when I get time - I have been meaning yo do this for a while but get very little time for such things due to the amount of support requests.... Just remember that offsets are just memory addresses, and must be read as the same type and/or size as they were written.

Please see the README.txt file, included in the zip file you downloaded: This has also been reported many, many times already... Please check the documentation and existing forum posts before starting a new post. I waste a lot of time answering the same questions again and again... I will look into making this the default option now Windows 11 is being used more and more... John

No! That is certainly not the case... Yes - 108.00 is 0x800 in BCD, which when read as an integer is 2048. So this is obviously not a straight conversion from hex to decimal. Yes, exactly! But, a simply a conversion from hex to decimal of 0x800 would be 2048, which is not the frequency... But you seem to understand...but your initial statement certainly isn't true! Ok - glad you found the function, that should make things easier. John

I am puzzled by this though - could you check by explicitly giving your lua Wnd window the focus by clicking on it - or maybe giving FSUIPC the focus. Really, the LuaTrapKeyEvent should be redundant now that FSUIPC is a separate application. The only way MSFS should see key presses when FSUIPC (or one of its lua processes) has the focus is if this is done explicitly via a keysend control... I don't think opening a Wnd window (and setting it topmost) will give the window the focus, as the focus should remain with the FS. I don't think there is an easy way to give a wnd window the focus. Best to just try this. I also suggest you activate logging for Buttons & Keys and open the logging console window. This will show you what keys are being received from the FS (meaning the FS has the focus) and which, if any, are being sent to the FS. I suspect that the keys are being received from the FS, but lets see... John

Maybe take a look at the MaxSteerSpeed ini parameter (and maybe also RudderBlendLowest) which allows you to control the amount of tiller/rudder blending for different groundspeeds. Also make sure both axes are calibrated properly. If using/assigning rudder in MSFS, assigning to FSUIPC's 'Steering Tiller' will cause issues -you should assign to Steering Set (under Send to FS as normal axis). This is the documentation section on the steering tiller (in case you missed it) from the FSUIPC7 User Guide (page 30): John

That is strange - I will look into it... Yes, please do - it will help me to see what is happening. Do that and I will take a look and get back to you, although it may take a few days. John

You can scale the axis values - add ,*0.5 to the end of the axis assignment line in your FSUIPC7.ini. You can adjust the scaling value as needed - see the section Additional parameters to scale input axis values on page 41 of the Advanced User guide. John

Ok, thats good to know, thanks. No - for future reference, always upload a full/complete log file, and zip it if too large. I need to see the beginning, the end, and most of the stuff un-between...! And in this case, the log was missing the lines that would have told me that you were using an incompatible WASM version. John

Thanks @Fragtality - I agree completely - the PFC driver must be monitoring either an offset or a control to know when to activate the displays (or turn the PFC on...). And I think this is the salient point: as the OP said it doesn't work like this as for all other planes, BUT the OP bound a button to activate this. So, if the OP could share what that assignment/binging is, then this may shed more light on the issue... Useful to know that he Fenix IS updating those offsets, so it can't be those. If its an event, which it seems likely, then it may be that the Fenix is just ignoring that event. You can send the event, but if its not handled, it won't be received (or logged) by FSUIPC - or the PFC driver. Logging would show this - i.e. if the OP tries the script you kindly provided and checks if the event sent is logged. Pete wrote the PFC driver, many years ago, in agreement with PFC. I have access to the source via github, but I really don't want to support this - it should be PFC that do this. I can maybe move the driver source across to my account and make it public if needed (and possible - I would need to talk to PFC).... I may take a quick look to see if there is anything obvious, but windows hardware drivers are an area about which I know next to nothing, and don't have the time (or inclination!) to do so. John

But this is what is confusing - there is no such button/switch. Control are only EVER sent to the FS, not to controllers. And the only thing to turn your stack on would be a power button on the stack itself. If pressing buttons on the stack are recognisd by FSUIPC, it must be ON.. But, I am now assuming that the problem is that the displays are not active for some reason... So, the PFC device must be monitoring an offset to determine when to light up the displays, and maybe this offset is not being populated by the Fenix? Have you tried monitoring the avionics master switch offset (0x2E80 or 0x3103) to see if those change value when the avionics are on in the aircraft? Or maybe the master battery offset (0x281C)? Maybe the PFC is waiting for one of those offsets to change to 1 before activating the displays (or 'turning on'). If that is the case, you could try either configuring your PFC hardware/driver to use a different offset, if that is possible, or maybe by spoofing the offset using lua, although I am not 100% sure the spoofing facility works if not being read from an external program, but you can try (see offset 0x0024). It would really help if you could respond to all of my questions - you seem to ignore most of them for some reason. Can you PLEASE explain what your binding is for the FBW that you use to get this to work - this would help enormously as, as far as I can tell, you have the same issue in the FBW without this binding. If I know what that is doing, it could shed some light on the issue with the Fenix (i.e. what is being used to trigger the displays).

Why are you using the right hand side? Axes are assigned on the left hand side...try that... You didn't need to do this - this is what I did to see what control to use. I mentioned that as that is how you determine what control to assign an axis or button to.

No, lvars should be available regardless of whether you are adding them to an offset or not. They must be available before they can be added to an offset, otherwise you would get an error when trying to add them to an offset. So something else must be going on, although I have no idea what... Are you sure that this is not just a timing issue - you have to wait for lvars to be received and available before using. I suggest that you retry with the logging console open (and set Debug level logging for the WAPI), and then you can see when the lvars become available. Or, if it doesn't work (without the lvar being added to an offset), wait a short while and try again. It is really the FSUIPC7.log file that will tell you what is happening, with appropriate logging enabled. I have no idea, sorry - check your SIOC documentation.

Why do you think FSUIPC7 is crashing? Do you have a crash report? Have you checked the FSUIPC7.log file? Are you aware that FSUIPC7 is iconised to your system tray once started? You can open the main window using Alt+F. Please see the User manual. John

ok...whatever works for you... This topic may be of interest - how to convert BCD to decimal in lua: John

This has not been "abandoned"... There is Plane Altitude, held in offset 0x0570: and also Indicated Altitude held in offset 0x3324: These offsets just hold the values as received from the FS. If the altitude reported in the offsets is 'way off', then this is an issue for Asobo - FSUIPC just reports/stores this data as received from MSFS. Check the Asobo forums - there are many reports on altitude issues, for example, see the following: https://forums.flightsimulator.com/t/incorrect-altimeter-readout/479399 https://forums.flightsimulator.com/t/if-qnh-is-lower-than-983-altitude-is-shown-incorrectly/470898 https://forums.flightsimulator.com/t/temperature-and-altitude-reporting-are-not-fixed-with-the-patch/431354 Note there are also two additional altitude simvars which are not held in FSUIPC offsets: PLANE ALT ABOVE GROUND Altitude above the surface PLANE ALT ABOVE GROUND MINUS CG Altitude above the surface minus CG If those are of interest, they can also be added to FSUIPC offsets - see the Advance User guide. John

If the server/client network addresses (or names) have changed, and you are using these in your Wideclient.ini (using the ServerIPAddr ini parameter) then you need to update that. Also, check that both client and server are in the same windows WorkGroup. You may also need to check your firewalls and add exceptions for the new server/client addresses. You can always temporarily disable any firewalls to test the connextion and to see if the firewall is an issue. If you are till having connection issues, and you are not using the ServerName or ServerIPAddr WideClinet.ini parameters, then I suggest you try adding them (ServerName preferred). You should really consult the WideFS documentation provided as all this is explained there, although in English I'm afraid... Regards, John

Glad you answered your own question! Not sure why you are reading the lvar value though...Presumably that is held in offset 0xA014, and so you can access that directly as a parameter of your event function.

Presumably the solution indicated above, i.e. by assigning the throttle lvars to offset, assigning your axes to those same offsets, and then scaling correctly. It is the actual scaling that @505Northman used that is missing as I gave several options...maybe he could respond... Otherwise, try setting up as detailed in this post and try the various scalings I provided to see which work... John

No, I only update (i.e. include the latest events.txt file) when I release a new version of FSUIPC7. You should not add them manually, you should download the latest events.txt file from https://hubhop.mobiflight.com/presets/, and use that to replace the one in your FSUIPC7 installation folder. Just click the Export presets button, followed by the events.txt button. You need to login to do this (create an account first if you haven't already). John

The log file you attached stops after 11 seconds...you really need to give more time. Did you have an aircraft loaded and ready-to-fly? Not according to the log, but as I say that stops after 11 seconds. Are you auto-starting FSUIPC7, or starting manually (and if so, why)? If the WASM menu items are disabled, this implies the the lvar information has not yet been received by FSUIPC7. This is only done once the aircraft is ready-to-fly (and after the LvarScanDelay period set). You are also using a very slow lvar refresh rate (Second). I suggest you change this to 6Hz. And please, always exit FSUIPC7 before attaching a FSUIPC7.log file. And the PMDG 737 takes an awful long time to load - be patient... John

No. What is FSUIPC actually doing? How are you 'using' the program? FSUIPC does nothing unless you tell it to. You really need to provide more information on what you are doing and what your issue is. John

What is this binding/assignment? Do you have anything assigned in the Fenix to turn the batteries on? If not, assuming the lvars are writeable, you can create a preset (in a file called myevents.txt file) to set the battery lvars, e.g. Fenix_A320_Batteries#$Param (>S_OH_ELEC_BAT1) $Param (>S_OH_ELEC_BAT2) Then assign to Prefix:Fenix A320 Batteries with a parameter of 1 for on and 0 for off. Alternatively, you can create separate presets for each battery, and separate presets for on/off if you prefer. The lvars.txt is one of the files I was after - I don't need to see your events.txt file (I have that) - I want to see your FSUIPC7.log file, generated with logging for events activated (in FSUIPC) and you turning on the avionics in the cockpit UI (as I asked for...). This would show any events/controls used by the avionics. It may also be useful to list the lvars before doing this, and again directly after. Comparing the two lists would then show if/what lvars have changed values. It may be obvious to you what your issue is, but it really is confusing to understand reading these comments.. I assume that you need to bind something (a switch or button) on your PFC stack to turn on the avionics in the aircraft, so lets try and sort that out first. And, from what I understand, you issue is nothing to do with PFC, it is the Fenix that is missing a function to turn the avionics on. The binding/assignment that does this for you in the FBW may help us understand... There also seem to be many presets already available for the Fenix (41 for the avionics alone, and 344 for the electrical systems) - have you looked through the preset list to see if anything is applicable (https://hubhop.mobiflight.com/presets/)?

The more posts here, the more confused I am... I thought that 1 was applicable: you say the button is working, but stanfard controls (Avionics On, Avionics Set, etc) do not work. And so I thought that you are looking for an assignment that when you press a button on yout PFC Radio Stack this turns the aircraft avionics on. But it seems that 2 is correct, as you say: YES So, if this is the case, what is turning the PFC displays on for other aircraft? Is this looking at an offset value, and if so, which one? If you can explain how this is configured for other aircraft, then maybe we can help... If its looking at an offset to do this, and that offset isn't being populated for the Fenix A320, then there are solutions available, assuming there is an lvar or something that holds this state (e.g. you can spoof the offset to an lvar value, if you can't change the offset that the PFC hardware is looking at for this). BUT, I still find this confusing, as you say: So you manually turn the PFC on for the FBW when the avionics are on. But then: YES which sounds like you want the PFC display to turn on automatically when the avionics are turned on in the plane... I think we are going around in circles here and neither @Fragtality nor I have a clear understanding of the actual issue...or maybe its just me... Normal behavior would be that you press a button on your hardware, this triggers the control, avionics turn on in the aircraft and your hardware displays light up. Is it that this is the case in other aircraft, but in the Fenix the aircraft avionics turn on, but your displays stay dark? If that is the case, then you need to know what is driving the displays to be turned on - is this an offset value, and if so, which?

So do I...it may be ok to duplicate the lvar name (not sure), but your index numbers are '0.1' and '0.1' when they should be '0.1' and '0.2', so there is no way to distinguish between those entries. And as they are both setting the (same) lvar to different values, I do not know which one will be used, although logging should tell you. Better to use the correct format, or switch to using presets, as advised. John

Could you list the available lvars for the Fenix please: Add-ons->WASM->List Lvars and paste/attach here from the FSUIPC7.log or FSUIPC7 main window. Please wait for a minute or two after the aircraft is loaded before doing this. Also, could you activate logging in FSUIPC7 for events and turn the avionics on in the cockpit UI and see what, if anything, is logged (in FSUIPC7.log), and also post that here. Thanks, John