John Dowson

Could you add offset logging for offset 026D as U8, set WAPI->Debug level logging and Extras logging and show me another log file from when you experience this issue. Thanks, John Later: also please add offset logging for 0258 as U32

The changes in 7.5.1 and 7.5.2 were minimal and I don't see how any of those changes can cause such issues. At what point (i.e. how long after FSUIPC was started) did you take that task manager screenshot? Your log shows a strange issue after around 2.5 minutes when the lua autos were killed and input events stopped and then requested: Do you know what caused this? Input Events are also stopped and re-requested at around 6 minutes: and the lua autos restarted after 9 minutes: All that seems strange... And later, after FSUIPC had been running for over and hour and a half, there are a lot of device scanning entries, starting here: which go on for 10+ minutes, and the log ends after 2 hours 7 minutes. So you kept FSUIPC running for the entire session even though you experienced these memory/performance issues at the beginning? When you get this issue, what happens if you exit and restart FSUIPC7? It does look like there are some issues with FSUIPC starting/stopping things when it shouldn't, and this is probably due to changes in either events. order of events or camera state changes in MSFS, and is most likely due to MSFS2024 updates and not FSUIPC updates (although you can go back to 7.5.0 if you want to confirm this). I will look into this, but I will probably require more logs with additional logging set. I will get back to you once I have investigated. John

Yes, I thought there might be performance issues... When a lua script is ran, the thread has to be created and the script compiled before it can be executed, This gives an overhead of 50ms+ (depending on hardware and available resources). When a lua script is triggered via a rotary (or on button/key repeat) the calls to start the lua can come before the previous lua has finished, and when this happens the previous lua invocation is killed and the next one started. This can result in nothing happening (as the scrip is continually being killed before it does anything) and a backlog of dying threads consuming resources. There are two things that you can do about this. The first, is to adjust/increase the LuaRerunDelay ini parameter. Default value is 66 - try incrementing by 20 until you reach a value where it works smoothly (although probably too slow...). You could also try setting the LuaAffinityMask ini parameter (undocumented) to an affinity mask to move lua thread execution off of the main core which may improve performance and allow a lower value to be used for the LuaRerunDelay ini parameter. The second, and better solution, would be to re-write the lua script to have it always running and re-act to events, which removes the thread creation and lua compilation overhead. It looks like you are currently writing a 'feed value' to offset 0x0D6C and then running the script which reads this value. Rather than doing this, you can have the script auto-ran, and rather than start the script with the Lua command, you send it the feed value using the LuaValue command. To auto-tun the script, you use the [Auto] (or profile specific [Auto.xxx]) ini file section - see the Advanced User guide, Here is the previous script adapted to be triggered via the LueValue command. -- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end function updateNav1(feed_value) currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if feed_value==10 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif feed_value==20 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif feed_value==30 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC end event.param("updateNav1") ipc.log("Nav1 ypdate lua script now running") John

Ok, thanks for the update. I wonder what caused this though...very strange! John

I have no idea - try the aircraft support...but if you have a working solution, I would just be happy with that... Sorry but most of that doesn't make much sense to me (I would need to see log and ini files for each test to make sense of this), I don't have this aircraft and I really cannot spend any more time on this as I have far to much to do at the moment....these forums are shutting down at some point this year and I need to move everything across to www.fsuipc.com and set up a discord server for support. I therefore have no time to look into this, especially as you have a working solution..

To be clear, something like the following, although this is untested: -- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end feed_value = ipc.readUB(0x0D6C) -- depending on which rotary encoder is turned and into which direction, MobiFlight sends a feed value to offset 0x0D6C currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if feed_value==10 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif feed_value==20 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif feed_value==30 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC John

The script looks overly complicated to me...not sure you need to be adding/removing the leading 1 so often, and rather convert to string to add/remove, you can just add (or remove) 10000 to the string value, and as lua is non-strict on types, you can just be lazy when adding/subtracting. i.e rather than: currentNav1 = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1_string = "1" .. string.format("%04X", currentNav1) -- convert decimal to string currentNav1_string_number = tonumber(currentNav1_string) -- convert string to number if currentNav1_string_number >= 11700 -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached then newNav1 = currentNav1_string_number - 900 else newNav1 = currentNav1_string_number + 100 end newNav1_string =tostring(newNav1) -- converting the decimal to a string, so that the leading 1 can be cut newNav1_cut = newNav1_string:sub(2,-1) -- cutting the leading 1 simpler would be currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1_cut = currentNav1 - 900 -- currentNav1 will be converted to a number implicitly else newNav1_cut = currentNav1 + 100 end -- -- etc -- Then to send: newNav1_BCD = convertToBCD(tostring(newNav1_cut)) -- convert to string before calling function ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC Not a big deal though - just FYI. Also, even though the aircraft does not have standby frequencies, they are most probably still available in the model. So what you can also do, which may be easier, is: 1. Set standby frequency to be the same as the active frequency 2. Inc/dec the standby frequency as desired using the standard FS controls 3. swap the active/standby You can even compress 1 & 2 and just read the current active frequency (in Hz as easier!), change the value to the new required frequency, set that as the standby frequency and then swap. Regards, John P.S. Also a good idea to declare your function(s) at the top of the script and mot embedded in the logic - this aids readability!

You can have it but it won't do anything because, as I said, it is the FS axis events that are calibrated, and this can be done before sending to the FS (done when using 'Send direct to FSUIPC calibration') or when the event is received by FSUIPC (and this event can be generated by FSUIPC when assigned with 'Send to FS as normal axis', or can be generated by the FS or other software, depending in the priority level it is sent at). So what does it use below 10kts? If you are using a preset for rudder and have calibration set up on rudder and this is having an effect, then what must be happening is that the preset is being executed and this is generating the FS rudder control/event (in the FS) which is then being received by FSUIPC, is being masked (i.e. blocked), but the value received is calibrated and then resent back to the FS (using the same event). But this surprises me, as I thought that the standard FS rudder controls don't work...if they do, why don't you just assign to those? When the aircraft is static, do you see the rudder move (external view) when you use the preset? If so, the preset must be working at all speeds, no? And if you activate logging for Axes Controls, do you see any rudder events when using the preset, and if so which one? Do you see any movement when assigned to Axis Rudder Set or Rudder Set (under 'Send to FS as normal axis')? And when assigned like this, can you set up monitoring for the lvar L:INPUT_RUDDER (see documentation on how to do this via the ini file) and see how that changes?

The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

👍

There are no changes in the 7.5 release that could cause this, and that was released at the beginning of December now...have you had this issue since then or have you only recently updated? You can try an earlier version to confirm if you like, e,g, https://fsuipc.com/download/Install_FSUIPC7.4.17.zip So your throttles are not assigned in FSUIPC? Can you be more explicit please - what do you mean by 'but will only slide back halfway'? And what do you mean by 'On single engine aircraft, only throttle 2 works'? In a single engine aircraft, there is only one throttle (throttle 1).... That message is informational and just letting you know that that preset isn't available for use as the name has too many characters. It is not being used (it is not even available for use!). Also looks like you manually reloaded the presets as that message is logged twice. Can you please activate logging for Axes Controls and test again, and show me / attach both your FSUIPC7.log and FSUIPC7.ini files. Just load the aircraft, move the throttles through the full range and back again, and then exit before attaching files.

Just from 1 to 0? Not from 0 to 1 to 0, or from 1 to 0 to 1? As it auto-resets, it should change to 1 value then back again (or to 0 then back again)... Maybe try: DU_MasterBright_Bright#(L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool) ! (>L:INI_CKPT_LT_DU_MASTER_BRT_INC, bool)

Can you attach your FSUIPC ini and log files, as well as your WideServer.log, WideClinet.log and WideClinent.ini. That will ar least give me an idea of your set-up. And please let me know how the avionics on the client PC is configured - are you using any other additional software? If you have not assigned/configured in WideClient / FSUIPC (and if ButtonScanInterval is set to 0) then these devices (whatever they are) must be assigned elsewhere, no? i am confused as to why do you think this is related to WideClient / FSUIPC if your client controllers are not assigned in FSUIPC...

Yes, that sounds correct, as that lvar is documented as a BOOL. I have no idea why it isn't controlling the brightness. When you inc/dev the brightness in the VC, do you see the lvar change value (and reset)? As I said earlier, you should ask on the InBuilds support forums as I do not have this a/c.

The only way they can be coming from WideFS is if you have set it up to do this and have assigned in FSUIPC. If that is the case, remove the assignments. Also, if you set ButtonScanInterval=0 in WideClient, it will not forward any button presses to FSUIPC, and so cannot possibly trigger anything there. What hardware to you have attached to your avionics PC, and how/where are they assigned? If you have not assigned in FSUIPC, why do you think it is coming from there? WideClient only talks to FSUIPC, not the FS.

Yes, you will need to give it a value...probably also a good idea to use repeat when assigning to that preset as well.

But why? Why not just do the correction I suggested? It was detected: However, it was not acquired as you now have registry issues: Continually unplugging and changing USB ports can cause registry issues. Please go back to your previous ini, make the changes I suggested and try again. If you still get issues, please attach your log and ini files again please, as well as the JoyScan.csv file. No, it is due to registry issues. If assi9gning in FSUIPC, we recommend that you disable controllers completely in P3D. If you don't do this, please make sure that you don't have dual assignments, i.e. an axis or button/switch assigned in both FSUIPC and P3D. Also, P3D has a tendency to auto-detect your controllers (if not disabled) and then make default assignments, which can cause issues if already assigned in FSUIPC. John

So it looks like those lvars are acting like a control/event - you set it to 1, this triggers the brightness increase or decrease and then the lvar gets reset back to 0. If you want to inc / dec again, you can set it to 1 again. Does it not work like that? If not, ask on the Inbuilds forums on how those lvars are supposed to work. I don't have this aircraft so cannot take a look here, sorry. John

Those are just events that are being logged....FSUIPC logs ALL events applied to the FS. Why do you think that those are coming from FSUIPC or WideClient? If you have no assignments in FSUIPC / WideFS, they won't be coming from there... Try setting logging for Buttons & Switches - that will log any button press that is triggering an assignment. If those events are being sent from your device and you don't want them to be sent, remove whatever you are using that is sending them. Note that many aircraft in MSFS continually emit certain events, and these event are different for each aircraft. These events are just noise really, and you can prevent them being logged using the DontLogThese ini parameter. No, as they are most probably not coming from FSUIPC or WideFS. FSUIPC is just logging them, not sending them.

You can try setting ButtonScanInterval=0 From the WideFS User guide:

All offsets in the documentation start with 0x and not $. But also only the starting offset is documented (together with the size), so rather than searching for a specific offset, just scroll down to you find the entry that documents the range for the offset you are interested in. Yes - almost all the offsets that have been allocated to 3rd party software use was done many years ago, before my time, and I have no idea what these offsets are used for in most cases! Cheers, John

Note that I also need to see the WideServer.log files for issues with WideFS... However, it should be obvious why it didn't connect the first time you ran FSUIPC7 if you look at your log file: FSUIPC7 never connected to MSFS and the WideServer was never started. Note that, by default, WideServer is not started until FSUIPC7 is connected and you have an aircraft loaded and ready-to-fly. The first thing you need to do is to delay the start of SPAD,next and vPilot until at lease FSUIPC is connected top the FS (i.e. add the CONNECTED keyword). vPilot could be started even later, using the READY keyword. Once that is corrected, try again and take a look at your log file. If you see the following message: 48891 **** SimConnect open event not received in required time limit: Re-connecting now... then you should adjust the DetectToConnectDelayAuto ini parameter. Please see the section Auto-tuning of initial start-up ini parameters in the Advanced User guide, or the following FAQ entry: John

Was this ever working then? Keysend works via windows messages. How are you starting the Discord PTT program? Have you tried directing the keypress to the Discord PTT program? If not, see the WideFS Technical guide from section Directing Key Strokes more precisely and onwards, John

Well, it cannot create the ini file if it isn't running. P3D starts FSUIPC from either the DLL.xml file or the Documents\Prepar3d v? Add-ons\FSUIPC6\add-on.xml file (depending on P3D version and maybe the components selected during installation), which are either modified or created when you install and has absolutely nothing at all to do with your ini file. Check you InstallFSUIPC6.log file for details. Changing the ini file can in no way affect the starting of FSUIPC6, so you must have also done something else. You can always try re-installing FSUIPC6 to see if that helps, and if not then show me / attach your InstallFSUIPC6.log file. John

Yes - its 5.1.4.