Jump to content
The simFlight Network Forums

PMDG event.offset is slower than MSFS event.offset


Fess_ter

Recommended Posts

Trying to discover if this is a PMDG issue or an FSUIPC issue.
Hardware Setup:
I have an Arduino based Radio Stack as well as an Arduino based 737 MCP, my design, build, and code, utilizing LUA scripting through FSUIPC.
Both have push buttons, switches, rotary encoders with acceleration coded in, and 7 segment led displays.
Both were used in the past with P3D in the past with no issues.

With MSFS and the evolution of FSUIPC7, functionality has remained largely the same.

The Issue:
I have 7 segment led display modules on both panels.
In  my LUA script, a MSFS default offset like 0x0C4E (Course or OBS) gets its changes detected via event.offset. The value gets sent to the Arduino to change the corresponding 7 segment display. It happens fast and smooth with no apparent delay and you can see the digits change rapidly with out skipping updates.


With the PMDG 737 on MSFS, the MCP event.offsets for the IAS, HDG, ALT and VS have a lag to them.
If I turn the corresponding rotary encoders on my hardware MCP or use the mouse to turn the knobs inside MSFS, the displays inside MSFS update fast and look great. But when the event.offset reads the change and sends it back to the Arduino to update those displays, there is a lag that causes skipped digits and makes the displays wonky to utilize while attempting to dial precise numbers.
The Left CRS and Right CRS on the MCP utilize MSFS's default offsets and are not affected.
When the PMDG first came out and FSUIPC7 was in its early stages, PMDG had their MCP 7 segment displays accessible through LVARS.
The event.Lvar was laggy to the Arduino display as well. My hope was it would be faster with offsets.

NOTE: I never had this issue with P3D FSUIPC6 and the PMDG 737.

So the question:
Is this a result of FSUIPCs poll rate of the PMDG offsets or is it something in the PMDG code with their broadcast rate that delays outgoing data for a moment?

~Thanks in advance, Fess.

Link to comment
Share on other sites

17 minutes ago, Fess_ter said:

Is this a result of FSUIPCs poll rate of the PMDG offsets or is it something in the PMDG code with their broadcast rate that delays outgoing data for a moment?

There is no poll rate of the offsets, and all offsets are treated equally by the event.offset function.  What would be different would be the update rate of the offsets. Most standard offsets are populated and the sim visual frame rate, whereas the PMDG offsets are populated when the PMDG (client) data is received/broadcast from the aircraft. I therefore suspsect that this is related to the data broadcast rate if the PMDG client data.

I can do some testing here at some point to check this, but I am not sure when I will have time to do this as I  have quite a backlog at the moment...

John

Link to comment
Share on other sites

9 hours ago, John Dowson said:

I can do some testing here at some point to check this, but I am not sure when I will have time to do this as I  have quite a backlog at the moment...

John

Looking at all of the posts, a backlog is quite understandable.
No problem. 😉
My issue is not a show stopper.

Thanks again and thanks for continuing to support and develop FSUIPC.

Link to comment
Share on other sites

  • 2 weeks later...

@Fess_ter It seems that lua scripts (and probably also FSUIPC7) are running approx 13x slower when FSUIPC7 is auto-started by MSFS compared to when it is manually started. This doesn't explain the difference between event.offset for PMDG offsets vs non-PMDG offsets (which is probably due to the data rate, but I will investigate when time permits), but worth knowing if you are having performance issue in your lua scripts.

John

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.