New Annunciators in NGXu not output

[Alpin-Flier]

Hi Pete

I use now the actual FSUIPC version 5.154. In my NGXu homecockpit I installed the new annunciators for "Takeoff_Config" and "Cabin_Altitude". But I don't get these outputs on $6C8E and $6C8F, meanwhile I can see them working in the VC view. I checked also with FS_Interrogate. Output values remain always on 0. Can you help me?

Thanks a lot and best regards

Urs Meyer

[Pete Dowson]

2 hours ago, Alpin-Flier said:

I use now the actual FSUIPC version 5.154. In my NGXu homecockpit I installed the new annunciators for "Takeoff_Config" and "Cabin_Altitude". But I don't get these outputs on $6C8E and $6C8F, meanwhile I can see them working in the VC view. I checked also with FS_Interrogate. Output values remain always on 0. Can you help me?

FSUIPC just reads the data from the PMDG iSDK interface and maps it to the offsets. 

I don't actually have any PMDG aircraft, so the mapping was done purely from the information supplied by PMDG, and checked for me by PMDG users.

The new NGXu offsets from 6C6A to 6C97 are all mapped as a block, so if you've found two wrong perhaps they are all wrong in your setup? To check please check other offsets for me: eg the ADF standby frequency in 6C6A, the pressurization altitude values (strings at 6C82 and 6C88)and the assorted FUEL switches from 6C91 to 6C97.

If those look and act correctly, then the wrong values in 6C8E and 6C8F must be wrong in the data the NGXu provides.

You can Monitor the whole range of values (6C6A-6C97) by putting this into your FSUIPC5.INI file (or just editing an existing [Monitor] section):

[Monitor]
Monitor4=6C6A,6C97
Display=1

Then values will be logged in the FSUIPC log as they change. You can see this in real time if you enable the console in FSUIPC's Logging options tab.

Pete

 

 

[Alpin-Flier]

The first value at 6C6A works fine. But then it seems, that offsets aim to wrong values. E.g. when I couple AT servo (by choosing TOGA), then 6C70 changes to 1, instead of 6C6E. Two DC busses (6C71, 6C72) show a 0, meanwhile they should be at 1. "Cabin altitude warning" at $6C8E outputs 48, and "Takeoff config warning" at 6C8F outputs always 0.

NGXu SDK outputs the values correctly as I can see using another parallel program (SIOC --> IOCP console). But I need the new values from FSUIPC due to my setup. Any idea how to proceed? Can I do some other tests?

Thank you so much and best regards

Urs

 

[Pete Dowson]

19 hours ago, Alpin-Flier said:

Can I do some other tests?

Yes please.

First, from the first thing you said ("6C70 changes to 1 instead of 6C6E") try looking at the value after 6C6A as if they are all 2 bytes further on (i.e add 2 to each offset). See if that gets you matches all the way down the list.

If so, skip the rest of this ...

Second, you could use FSInterrogate's memory display option to display all of 6C6A - 6C97 in hex, and make a copy of that for me to see. Try to set as many of those values to something you know and list them as far as you can, so I can try to match them up.

Third, if none of those prove fruitful, or you find it too difficult to tell, I'll make an FSInterrogate file for you to load in one of its Windows so you can monitor the vlaues in their proper format, and more easily make adjustments to the offsets in the Window until the values match what you expect.

If there is really a mis-match then either the NGXu isn't matching what I'm told in the SDK, or, probably more likely, I have made an error and my previous testers weren't thorough enough!

Pete

 

 

[Alpin-Flier]

I made the FSUIPC console show all value changes from 6C6A to 6C97, as you proposed. So I can also see, what values change when I dial the  stby of ADF. The result:

Over the whole range of ADF here are only changes shown at 6C6C. At little changes only two digits ("01"   "03"   "05" ...), at higher changes  2 x 2 digits ("49 1D"  "31 21" ....)

This would confirm, that there is a two-byte shift, isn't it? I also made changes to FlightAlt and LandAlt, but the behaviour is strange: The first change shows:

6C7D      B9 98 41

6C88      60 C2 AB 5E 88 3C 98 41

6C7D     00 00 00

6C88     00 00 00 00 00 00 00  00

and then changes are blocked (no response any more). I hope this helps. If not, I will make the FSInterrogate copy.

Urs

 

[Pete Dowson]

9 minutes ago, Alpin-Flier said:

This would confirm, that there is a two-byte shift, isn't it?

Not sure. I'll make n FSinterrogate file for you assuming that and you can test more easily.

10 minutes ago, Alpin-Flier said:

I also made changes to FlightAlt and LandAlt, but the behaviour is strange: The first change shows:

6C7D      B9 98 41

6C88      60 C2 AB 5E 88 3C 98 41

6C7D     00 00 00

6C88     00 00 00 00 00 00 00  00

and then changes are blocked (no response any more).

None of that makes sense I'm afraid.

[LATER]

Here's the FSQ file. Put it into the FSInterrogate folder. Then you can load it into a Window (via the Windows menu then "Load"). Then you can select (highlight) all the data entries and opt to read them once or repeatedly, to see changes.

You can try adjusting the offsets up or down to see if you can get better matching.

Note that the twp offsets I've tabulated beyong 6C97 may not react -- depends if the FSUIPC mapping finishes where documented.

Pete

NGXu Offsets FSQ.zip

[Alpin-Flier]

Sorry, Pete, I cannot load FSQ files, only FSI. FSInterrogate tells me to use a newer SW version. I tried to load it from your SDK site, but there is no change. And the Liljendal page refers to your page for downloads. Where is the clue?

Urs

[Pete Dowson]

13 minutes ago, Alpin-Flier said:

I cannot load FSQ files, only FSI. FSInterrogate tells me to use a newer SW version. I tried to load it from your SDK site, but there is no change.

I am using the one from our page -- the one included in the SDK. It has not changed since then!

FSI files are those which provide information for the main display, NOT the separate windows.

I think you are not following my instructions.  Go to the FSInterrogate  menu.  See the "Windows" entry, 4th one from the left, between "FlightSim" and "Help"?  Click on "Windows". You will see a list of QD windows ("Quick Data"). Select any one, then use the Load option to load the FSQ file I provided.

Pete

 

[Alpin-Flier]

Sorry, but understood and corrected now. Please find enclosed two screenshots, one at holding, the other with TOGA activated. 6C70 shows correct result now. Then several busses show a 1 and switch off, when they are down. But  busses from 6C7D upwards show 0 instead of 1. 6C90 and 6C91 don't change and remain on 0. To allow a comparison, I add an SIOC screenshot, that shows the same conditions as the holding one. Please let me know, if I can make other tests.

Best regards

Urs

 

[Pete Dowson]

33 minutes ago, Alpin-Flier said:

Please let me know, if I can make other tests.

I wanted you to select the option to "continuously read" (bottom left on the QD window screen) and operate assorted things to see which ones actually change each time (onr change at a time please to avoid confusion). It's the only way to actually locate the correct offsets. A static view isn't so much of a help as you telling me which ones are changing correctly.

I don't know IOCP and i'm really not sure what it is showing me.

The other thing that occurred to me is whether PMDG updated the NGXu after the SDK I received was made (right at the first release), so, in order for me to check that, perhaps you could go to your PMDG SDK folder, find the file "PMDG_NG3_SDK.h" (which is the name of the one supplied to me), ZIP it an attach it for me to cpmpare.

Pete

 

[Alpin-Flier]

1 hour ago, Pete Dowson said:

I wanted you to select the option to "continuously read" (bottom left on the QD window screen) and operate assorted things to see which ones actually change each time (onr change at a time please to avoid confusion). It's the only way to actually locate the correct offsets.

That's what I did. And so I could tell you, that 6C70 and some DC busses change accordingly. But when I trigger the "takeoff config annunc", then not any of the values changes. It looks like there is no offset above 6C7C changing its value. Also Flight and Land Altitude show empty fields resp. a 0, when changed from ASCII to number. Also dialing does not change it.

The IOCP table has the same input order as you use for the new SDK  offsets. You can compare most values by names. 1612 corresponds to your 6C6A.

Please find enclosed the actual .h file.

Urs

PMDG_NG3_SDK.zip

[Alpin-Flier]

Let me send you a recent logfile, where you can see, that something strange happens to some offsets above 6C7C. I don't touch the sim, but there are wild outputs for a while. At the end you can see the correct switching for the A/T servo. Perhaps it helps...

FSUIPC5.log

[Pete Dowson]

I've got both the .h file and the LOG ready to look at tomorrow. I'm also going to search back for the details obtained by the original tester, last year to see which offsets were checked then. I'm pretty sure we checked both a couple of early ones and the two which should be easy -- the character strings for the pressurisation altitudes.

None of those hex values being logged near or at the altitudes are ASCII caharacters for numerals as one would expect.

It's late here. I'll be looking at it when I get back from taking the dog for a walk tomorrow.

Pete

 

[Pete Dowson]

Before taking the dog for a walk, I've added some extra logging, with more explicit values named and for both the data being received from PMDG and that in the offsets.

Please rename your current FSUIPC5.DLL or save it somewhere, and instead put in the test one attached (it is 5.153g, a predecessor to the 5.154 you were using).

This will log the information I need the first time anything in it changes AFTER you visit the FSUIPC Options. You don't need to do anything there, just call it up and exit, then make one change in the NGXu.

This should enable me to compare exactly what the NGXu supplies and what I've mapped into the offsets. I have a feeling that possibly one of the calculations of the offset positions relative to the data supplied is incorrect. (I couldn't make a straight copy, which would have been easier and less prone to error, because then I would break compatibility for NGX users changing over to the NGXu).

Pete

FSUIPC5153g.zip

[LATER]

Here's another one, 5.153h. After the above test, please save me the log and run the same test with this version. I've juggled the mapping slightly to see what changes, if anything. Then please provide both logs.

FSUIPC5153h.zip

[Alpin-Flier]

Funny! I also go outside with my dog (a 4 year old Husky lady) for long walks. Walking like that has often resulted in good ideas ...

I hope I got your instructions well. Please find enclosed the resulting log file. Again many wild writes after start. Then I did two changes, the first on 6C70 working fine. The other change was the CVR Test, but there no output is visible, meanwhile I can see in the VC the lamp going on.

Urs

FSUIPC5.log

[Alpin-Flier]

This is the log file with the new dll. The wild outputs seem to have disappeared. I just put the weather to "clear skys". Or it is your new dll or the change in weather?

Urs

Edit: the first two lines after your test blocks are due to center fuel tank, that I had to switch off (working 6C91 and 6C92). Then the AT servo command is visible on 6C84. By the way: operating TOGA not only couples the servo, but makes also throttles go up. As a result the takeoff warning should appear. In the cockpit yes, but not in the log file.

FSUIPC5.log

[Pete Dowson]

2 hours ago, Alpin-Flier said:

This is the log file with the new dll. The wild outputs seem to have disappeared. I just put the weather to "clear skys". Or it is your new dll or the change in weather?

The weather has nothing to do with this. Just entering the Options and Cancelling or OKaying out would make the log entries. No need to do anything whilst there.

I have an error in the code I added, making all the "Results in .." values wrong, probably zero. 

The first thing I don't understand is that the ADF_StandbyFrequency times 10 is 2109472, making it 210947.2. No matter what units that's in it makes no sense. What was it set to? Even treating it a BCD (binary coded decimal) it makes no sense. I need to relate it to the displayed value.

Note that ALL of the values listed in the "Actual NGXu ..." section are directly from the data supplied by the NGXu using the structure in their SDK h file. In other words they have not been mapped or otherwise molested by FSUIPC.

It would also be very useful, please, for you to actually set the pressurisation and landing altitudes to some predictable (known) values so I could see those. The 6 characters are supposed to be 5 digits zero terminated, but neither are. I think the 01 is intended to be shown as a dash and 00 as blank, but again that isn't documented. So please set both and tell me what you set them to.

Meanwhile i will work on the test code to make the secong part, the Mapped value, log correctly.

Pete

 

 

[Pete Dowson]

Okay. Here is 5.153i to test with. Hopefully the second part of the added logging will now work correctly.

Please don't restrict yourself t making one change. Make a change (note for me wha it is) for each visit to the Options, so I get a different log set for each.

Pete

 

FSUIPC5153i.zip

[Alpin-Flier]

I tried my best...  This is the sequence I tried. May be that there is an additional Option call inbetween. My brain is not the best any more...

ADF at start on 3300, flight alt on 10000 ft
FSUIPC Options
ADF changed to 10000
FSUIPC Options
TOGA
FSUIPC Options
Battery switch off, then on
Standby Switch off, then on
FSUIPC Options
CVR on, then off
FSUIPC Options
change flight alt from 10000 to 11000 ft
FSUIPC Options

The required offsets are still missing resp. inactive. No outputs between Option calls. At TOGA I get the servo coupling command, but not the take off config warning.

Urs

FSUIPC5.log

[Alpin-Flier]

I made a test on ADF. I can put offset 6C80 in the first specific value check on your log window and give it the format U32 and then activate the FS window. So the value is shown correctly.

Urs

[Pete Dowson]

31 minutes ago, Alpin-Flier said:

The required offsets are still missing resp. inactive. No outputs between Option calls. At TOGA I get the servo coupling command, but not the take off config warning.

Well, the data FSUIPC is receiving from PMDG is definitely mapped okay. the first part of each of the added logging actually shows what the PMDG data has provided, at least according to the structure PMDG provide in the .h file -- that IS the actual structure used in FSUIPC.

So, I can see no way forward. As far as i can see FSUIPC is doing exactly what it should be doing. I just don't understand why the data it provides don't match the document PMDG has published.

20 minutes ago, Alpin-Flier said:

I made a test on ADF. I can put offset 6C80 in the first specific value check on your log window and give it the format U32 and then activate the FS window. So the value is shown correctly.

Sorry, I'm not really understanding what you are saying. Do you mean the value 2109472 is correct for the standby ADF frequency you have set in the cockpit?

I have found an install package for the NGXu I apparently used last year to get FSUIPC working. i've installed in into my development system copy of P3D4 so that I can test it all myself (again?) ... however it either hangs P3D4 solid when selected, or causes P3D to crash. Usually the former. This applies even if i load P3D with its default flight. 

I use Windows 7 Pro on my development system. i am wondering if the NGXu isn't compatible with Win7. However, i'm sure it must have worked okay last year when i originally tested it all. It's all very odd. (I've never had much success with using PMDG aircraft).

Not sure how to help further with this at present. i'll get back to you if I can work something out.

Pete

 

[Alpin-Flier]

24 minutes ago, Pete Dowson said:

Sorry, I'm not really understanding what you are saying. Do you mean the value 2109472 is correct for the standby ADF frequency you have set in the cockpit?

That sounds strange, but I really can see the correct frequency in that window (in the log file too) and I also don't know, how the strange value is converted to the correct frequency.

29 minutes ago, Pete Dowson said:

Not sure how to help further with this at present. i'll get back to you if I can work something out.

That is very kind of you. Thank you so much for the extensive cooperation. Since I need only two values, that are shown correctly in SIOC, I will send them from there to FSUIPC using two dummy vars and read then these vars from FSUIPC into my other HW driver to control "Takeoff Config" and "Cabin Altitude". Not very elegant, of course, but effective.

Thank you for all your help and let me know, when I can test some issues for you (and me, of course ;-))

Now it's doggy time. All the best

Urs

[Pete Dowson]

41 minutes ago, Alpin-Flier said:

That sounds strange, but I really can see the correct frequency in that window (in the log file too)

Sorry, I don't know what frequency you have set. Which long entry contains the one you say is correct?

42 minutes ago, Alpin-Flier said:

Thank you for all your help and let me know, when I can test some issues for you

Do you use any of ther other NGX offsets, i.e. the part which isn't new for the NGXu? If so are they all correct?

I've managed to get the NGXu working on a different PC and I can now do the logging myself, but I cannot figure out why what I'm looking at is so wrong. Another problem is that, though i fly a 737NG myself (I have a 737 cockpit and use ProSim737 software for all the systems and displays), I have great difficulty trying to do things on the PMDG panels. It all seems so, er, clunky.

Pete

 

 

[Pete Dowson]

In order for me to get this sorted out, could you supply some other files? Let me explain ...

When I load the 737NGXu, after previously loading a simple flight with an aircraft in cold &.dark state, the 737NGXu starts up with electrical power on and most other switches on.  The FLT ALT and LAND ALT momentarily show reasonable default values, then go blank ( - - - - -).  After a few more seconds warnings and all sorts of sounds occur.

There appear to be no pre-made flight setups for this aircraft. I would have expected to find at least some options, like to start cold and dark, or ready to fly, whatever.

This is all from a fresh install, just registered. I noticed it talked about an "Operations Centre". Do I have to run a separate program to get the thing to be usable? (Sorry, I would read some of the documentation, but i'm not really interested in getting the program working, only in finding out why the data is all wrong).

To make this less of a load for me (I've been putting off other things I should really be working on), is it possible for you to set the aircraft up in a decent way, with defined settings, so that I can start from there? I assume when you save a flight the NGXu state is also saved? I'd need the P3D flight file and any NGXu saved files to go with it. Would that be okay?

I did see a COLD&DARK.fxml.sav file in its folder. I assume that should go with a saved P3D flight with the same name, so it is odd none was supplied -- at least none got installed into the Documents folder for P3d4 files.

Thanks,Pete

 

[Alpin-Flier]

47 minutes ago, Pete Dowson said:

Sorry, I don't know what frequency you have set. Which long entry contains the one you say is correct?

I start always with 3300. Now I made some test with different formats. You can see it in the joined log file. I increased the value to 3301 and then back to 3300. No idea, where the long number in your test block comes from.

I use FSUIPC for about half of my cockpit without any problems 🙂. The other half is Opencockpits stuff controlled via SIOC and OC4BA. For me as an engineer it is very interesting knowing both platforms...

Urs

FSUIPC5.log