Hi PMDG friends

I am actually taking into operation my B737 overhead from Opencockpits. There are different LEDs with full and dimmed brightness. Unfortunately there is only one, that is fully supported by PMDG NGX:

unsigned char    FUEL_annunXFEED_VALVE_OPEN;    // 0: Closed  1: Open  2: In transit (dim)

Moreover I get 1 for "in transit" and 2 for "Open". This could be an error of the driver (OCP4NGX), but please check. The OC hardware supports directly 1 for open, 2 for dimmed.

All other bivalent LEDs get only boolean from PMDG. I can make the brightness step with an SIOC script, but it would be nice getting correct values from PMDG in the future.

Another surprise was the general use of LED outputs. They work without problems in operation. But the light test does not source a 1 on all individual outputs. So the outputs do not represent the LED states 1:1. Would it be possible in the future to do this? Then cockpit builders can forget all light-test, cold and dark and individual light controls scripting. Just use LED outputs and bring them onto panel. The rest is done by PMDG program. That would be great!!!!!!!!!!!!!

Any comments are most welcome. Thank you in advance.

Best regards
Urs
 

 

 

This could be an error of the driver (OCP4NGX), but please check.

 

The value is the value. The maker of the driver will have to address how they're interpreting the value.

 

 

 

All other bivalent LEDs get only boolean from PMDG. I can make the brightness step with an SIOC script, but it would be nice getting correct values from PMDG in the future.

 

In order to work a 737 into the Sim Center, the NGX would need to get a re-visit with more of this hardware-specific kind of thing in mind (technology that has been developed to get the 747 QotS II product to work would be carried back into the NGX to make this work).

 

 

 

Urs

 

Full names - first and last - in the forum, please.

Hi Kyle

 

Thank you very much for the fast reply.

 

 

 

The value is the value. The maker of the driver will have to address how they're interpreting the value.

 

I think the driver just takes the value it gets (0, 1 or 2) and hands it over to SIOC variable. Can't imagine that it exchanges numbers. Therefore my question.

 

 

 

In order to work a 737 into the Sim Center, the NGX would need to get a re-visit with more of this hardware-specific kind of thing in mind (technology that has been developed to get the 747 QotS II product to work would be carried back into the NGX to make this work).

 

Is there a public document where we can see, what is planned resp. place wishes for a NGX re-visit?

 

By the way, in general I am very happy with your fantastic program. My problems have only to do with homecockpit setup, which doesn't belong to your main user group. But I am gathering a lot of practical experience and can perhaps help to find good solutions for optimised hardware control. 

 

Best regards

Urs Meyer

 

 

I think the driver just takes the value it gets (0, 1 or 2) and hands it over to SIOC variable. Can't imagine that it exchanges numbers. Therefore my question.

 

Even if it were just passing the number, one would imagine the hardware manufacturer would make the proper adjustment.

 

 

 

Is there a public document where we can see, what is planned resp. place wishes for a NGX re-visit?

 

Not sure what you're asking for here.

Finally I have found the reason for my confusion concerning FUEL_annunXFEED_VALVE_OPEN. The values are output correctly by PMDG, 2 for in transit, 1 for open. The only small error is found in the sdk definition

 

"unsigned char    FUEL_annunXFEED_VALVE_OPEN;    // 0: Closed  1: Open  2: In transit (dim)"

 

The remark (dim) should be behind "Open". Now it is really up to the HW manufacturer to optimize the data transfer.

 

Concerning the document: I mean sort of a change list, as it is used in program version history files, but directed to coming versions.

 

Urs Meyer

 

 

Finally I have found the reason for my confusion concerning FUEL_annunXFEED_VALVE_OPEN. The values are output correctly by PMDG, 2 for in transit, 1 for open. The only small error is found in the sdk definition
 
"unsigned char    FUEL_annunXFEED_VALVE_OPEN;    // 0: Closed  1: Open  2: In transit (dim)"
 
The remark (dim) should be behind "Open".

 

Got it. Thanks for pointing that out.

 

 

 

Concerning the document: I mean sort of a change list, as it is used in program version history files, but directed to coming versions.

 

A change list implies that the changes have already been made. We don't have a list of things since we haven't gotten that far yet, but we would need to alter the software enough to run something like this with the appropriate refs: http://www.flightdecksolutions.com/professional/b737ng/