Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hello all, 

 

I am using FSUIPC for loads of good stuff within the sim, like mapping controls and what not. I am also using it as a bridge between the sim an the application self loading cargo. I mainly fly in the PMDG NGXu and as of late I am getting anomalous readings with regards to engine N1 outputs that lets SLC go haywire. For some reason, when engines are off N1 values should be reading 0000000000 but in my case they are reading like -33300000 or whatever. This prevents the application from working correctly. The folks over at SLC say that SLC only reads the data so they cannot help on their end.

 

Any idea what can be done to get these readings back to normal?

 

Regards.

 

Daniel W

Posted
17 minutes ago, pijnackerpilot said:

I mainly fly in the PMDG NGXu and as of late I am getting anomalous readings with regards to engine N1 outputs that lets SLC go haywire.

Where are you reading this data from? From the PMDG offset area (via the PMDG SDK) or are you using standard offsets?
Please let me know the offsets being used (or how you are getting these values) and I will take a look.

John

Posted

I got a hold of Steve over at SLC and he is telling me the following (Text is very light of colour. select and drag please)

 

Engine1N1 > 0x0898

Engine2N1 > 0x0930

Engine3N1 > 0x09C8

Engine4N1 > 0x0A60

 

all declared as short (UInt16) variables.

Posted
43 minutes ago, pijnackerpilot said:

Engine1N1 > 0x0898

Engine2N1 > 0x0930

Engine3N1 > 0x09C8

Engine4N1 > 0x0A60

 

all declared as short (UInt16) variables.

The description for offset 0x0898 reads as follows:

Engine 1 Jet N1 as 0 – 16384 (100%), or Prop RPM (derive
RPM by multiplying this value by the RPM Scaler (see 08C8)
and dividing by 65536). Note that Prop RPM is signed and
negative for counter-rotating propellers.

In FS2004 this also now gives the Robinson model’s RPM, when
scaled by the RPM scaler.

and simply holds the value of the indexed simvar TURB ENG N1:1. Therefore any values you see in this offset will be coming from P3D.

1 hour ago, pijnackerpilot said:

and as of late I am getting anomalous readings

So the readings used to be ok? What has changed on your system?
You could try logging those offsets in FSUIPC to see if the values match those shown in SLC.
 

Many complex add-ons implement their own subsytems and dont use the default P3D simvars. PMDG, for instance, provide  their own SDK and have a dedicated offset area. Have you checked this to see if the information you need is available in the PMDG offset area?

Also, as the offset description says 'as 0 – 16384 (100%)', I don't see how you can be getting a value of -33300000, as that is outside of the range of a short int (-32768 to 32767 unsigned or 0-65535 signed)....

John

 

Posted

Yes until two weeks ago, readings were ok. Heck, even a couple of days ago, they reverted from going like these:

https://pasteboard.co/O6F3Je2tAt0g.png

to normal. As of yesterday. They are all weird again. I have not changed anything major to my settings, other than a bit of fooling around in FSUIPC to get reversers mapped with buttons.

All else seems to be ok. I don't get any other issues. I just want this to sort out so we know what is happening here.
How do I log these readouts in FSUIPC?

 

Posted

Many complex add-ons implement their own subsytems and dont use the default P3D simvars. PMDG, for instance, provide  their own SDK and have a dedicated offset area. Have you checked this to see if the information you need is available in the PMDG offset area?

 

I have no idea what this means and how I check this.

Posted
1 minute ago, pijnackerpilot said:

I have no idea what this means and how I check this.

You could start by taking a look at the PMDG 737NGXu offset document Offset Mapping for PMDG 737NGX and 737NGXu.pdf.

You should also try with a different/stock aircraft/jet.

John

Posted

So I enter the provided offsets in the tab and then do what? I get no readout window or whatever, 

Secondly, in that document, I look up what??? According to the folks at SLC, the readouts I get are not what they expecting from the NGXu.

I am sorry but this is rather unclear to me. 

Posted
Just now, pijnackerpilot said:

So I enter the provided offsets in the tab and then do what? I get no readout window or whatever, 

You could try reading the documentation on logging....

You need to select where to log the information. Check 'Normal log file' and the values will be written to your FSUIPC6.log file. You can attach that here so that I can see the values.

1 minute ago, pijnackerpilot said:

Secondly, in that document, I look up what???

I am only suggesting you check this for the values you need....maybe PMDG implement their own systems for this. However, if it was previoulsy working ok, O suspect that something else must have changed....

3 minutes ago, pijnackerpilot said:

According to the folks at SLC, the readouts I get are not what they expecting from the NGXu.

This is why I have suggested logging those offsets, so we can see what FSUIPC is holding for those values.

2 minutes ago, pijnackerpilot said:

thing is - i'm not entirely sure how you're managing to show "-xxxxxxxx" .. it's a uint, which means "unsigned" integer. It can't be negative.

Nor am I! How can SLC be displaying such values if its an unsigned int...only SLC can answer this question...
But it will help if you can log those offset so we can actually see what the source of those values actually is...

John

Posted
2 minutes ago, pijnackerpilot said:

A sim window with the readings from offsets 0898 and 0930

 

https://pasteboard.co/scpTueFASVL0.png

Please stop with pasting images. I need to see your files - I will not look at images....

If the logged values are different than those shown in SLC, you need to contact SLC to find out why...

If the logged values are not correct, then ask on the PMDG support forums.

FSUIPC just requests these values and stores them in offsets for access by 3rd party programs, such as SLC.

John

Posted
34 minutes ago, pijnackerpilot said:

A log of the flight I am currently doing. Let me know if you find something out of the ordinary.

No, but you are logging the values incorrectly. You are logging them as U8, an unsigned byte, whereas they are in fact two byte unsigned shorts, so should be logged as U16.
This is why you are only seeing values in the 0-255 range (the range for a U8).

So, change your logging to U16 and repeat your tests - and you do not need IPC read logging activated.
You can also see the log in real-time if you open the logging console. Look at the logged values and compare to what you see in SLC. If they are different, then report this to SLC,

You could also log the N1 %age values, held as 8-byte floating point values in offsets 0x2000 and 0x2100.

john

Posted

I did another flight where this anomaly did not occur. I think it has something to do with me having mapped reversers to the action throttle decrease for separate throttles 1 and 2. I noticed that at the start the axis was deployed. Anyways, I don't know. I did some tinkering and logged using the unsigned 16 b. setting. Tomorrow I will fly again and hopefully I'll have more then. 

FSUIPC6.log

Posted

The log you posted looks reasonable with the N1 values starting at 4401 and then reducing to 0. Did SLC show the same?
As I have said, the FSUIPC offsets are just holding the values as received from the FS. If they are different in SLC, then it is an issue with SLC.
If the N1 values reported in those offsets are not correct, then it is a an issue with the aircraft.

John

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.