Solution to detecting light state changes in PMDG overhead

[jgedrim]

Hi Pete,

I believe that I have come up with a solution to detecting when lights are on or off in the PMDG overhead panel and would appreciate your thoughts. I must warn you in advance that with my testing to date, the panel has to be open and the panel has to be unobstructed but does not have to be the active window. Also this only works in Windowed mode.

The principal is that when an overhead light is switched on, a bright colour is displayed in certain areas of the display , and when it is switched off then a dark colour is displayed in the same areas.

If we save the co-ordinates of a pixel that is normally lit when a light is on then we can monitor this pixel at a regular interval and set a fsuipc bit for that switch light i.e. 1 when a bright colour and a 0 when a dark colour.

I do not think it is possible just to save the colour of the pixel in the two states due to the lighting logic used in the flight sim. i.e. at different times of the day the light of the panel will change colour. The switch will still look red, orange, green, blue etc. but will be a different shade of that colour and its RGB components will vary slightly.

Determining a dark vs light colour can be done in at least two ways"

1) The hard and time consuming way is to convert the RGB colour to HLS and then track changes in the Lightness component. Ouch.

2) The easy way (may not work in all cases but does for the PMDG B747 overhead which has dark grey switches and lights) is just to track changes in the R, G or B components

i.e. red and orange lights will have a high R component when lit and a low R component when unlit

green lights will have a high G component when lit and a low G component when unlit

blue lights will have a high B component when lit and a low G component when unlit

white lights will have high R,G and B components when lit and low R,G and B components when unlit

Remember that when R = G = B we have a shade of grey with 0xFFFFFF = white = very light grey and

0x000000 = black = very dark grey

An example of this (measured in daylight conditions) is:

The Gen Cont switch for Engine 1 on the PMDG B747 has an orange OFF light at the bottom of the switch.

When it is on, the RGB colour in Hex is 0xA57321 (i.e. predominately a mix of red and green)

When it is off, the RGB colour in hex is 0x101018 (i.e. a low consistent mix of red, blue and green i.e. grey)

If we just look at the R component, then we can assume that if its value is greater than 0x77 then the light is on

and if its value is less than this, then the light is off.

The basic programming steps (which I am busy with in VB6 as I haven’t programmed in C for at least 13 years) are something like this:

1) Get the window handle of the overhead panel by using the panel name (on B747 it is 'overhead') and the User32.dll

function FindWindow

2) Get the Device Contect of this window by using the User32.dll function GetWindowDC.

Using the DC instead of the Screen position allows the panel to be moved without changing the position of

the pixel to be tested. (0,0) is always the top left of the panel window.

3) Get the Co-Ordinates of the panel window using the User32.dll function. This is saved with the pixel co-ordinates

so that the pixel position can be calculated if the panel is resized.

3) Get the colour of the pixel to be tested by using the Gdi32.dll function GetPixel

4) Convert the colour to a hex string i.e. right("000000" & hex(colour),6) in VB

------- this is how far I have got in programming and testing ----------

5) Test the required R, G, or B component and then set the required FSUIPC offset bits for that light.

Maybe you have some ideas that will improve on this logic.

Thanks for a great program (FSUIPC) and all your hard work. Your mouse macros got me started on my B747 cockpit project.

Regards

John Gedrim

(A pommie living in South Africa)

P.S.

Thanks to your program, I have the correct offsets for the B747 and B737 MCP switches and lights. The ones that I found on the internet are actually for the FMC directives to the autopilot. i.e. Heading fluctuates in LNAV on B737 and B747 and Altitude is locked altitude in VNAV on B747.

I am sure that you have these but if not then let me know and I will forward them to you.

[Pete Dowson]

I believe that I have come up with a solution to detecting when lights are on or off in the PMDG overhead panel and would appreciate your thoughts. I must warn you in advance that with my testing to date, the panel has to be open and the panel has to be unobstructedDetermining a dark vs light colour can be done in at least two ways" ...

I'm not sure of the point of doing this if you have to have the panel visible on screen. Surely the only use of knowing indications is to display them on real hardware instead, not as well?

Get the Co-Ordinates of the panel window using the User32.dll function. This is saved with the pixel co-ordinates

so that the pixel position can be calculated if the panel is resized.

I assume you can reliably get to a pixel you want for any resied scaling?

Test the required R, G, or B component and then set the required FSUIPC offset bits for that light.

Er, now that does confuse me. What has an FSUIPC offset got to do with any of this? Or do you mean set some user-assigned bit which will be used by some hardware LED driver?

Maybe you have some ideas that will improve on this logic.

No, sorry. I've never been into graphics, and really anything involving testing unwanted images on screen seems to me to be missing the point of having a hardware cockpit. Wouldn't it be better to just find a model which can be utilised correctly. Or, do as many have done, use external logic for the systems you are trying to integrate from the PMDG model (i.e. via such programs as Project Magenta's pmSystems.

If this is all for FSX, you may be interested in some additional programming facilities I'm currently adding to FSUIPC4 -- to allow user threads running programs written in LUA (see www.lua.org) to be instigated automatically or via control assignment (like the FSUIPC Macros), with easy fast and efficient access to FS innards via FSUIPC offsets. I think these would be capable of being used to simluate many of the subsystems currentl;y needing sophisticated add-on panels.

Thanks for a great program (FSUIPC) and all your hard work. Your mouse macros got me started on my B747 cockpit project.

Well, the facility for Lua plug-ins was the next logical step I saw after doing the macro facilities.

Thanks to your program, I have the correct offsets for the B747 and B737 MCP switches and lights. The ones that I found on the internet are actually for the FMC directives to the autopilot. i.e. Heading fluctuates in LNAV on B737 and B747 and Altitude is locked altitude in VNAV on B747.

I am sure that you have these but if not then let me know and I will forward them to you.

No, actually I don't have any PMDG offsets -- in fact I don't use any PMDG panels, so i have no use for them. Also, I would not publish such information because I have a good relationship with PMDG and they see this information as proprietary.

Regards

Pete

[jgedrim]

Hi Pete,

Thanks for your comments.

The idea is that in a hardware cockpit, you have a small overhead window on your main panel, next to the PFD for example which is covered by the panel hardware so not physically visible, and then set the actual switch lights in the overhead hardware.

Regards

John

[Pete Dowson]

... covered by the panel hardware so not physically visible, and then set the actual switch lights in the overhead hardware.

Ah, I see. Yes, I suppose that's an interesting solution. You must really really like the PMDG aircraft to go to such lengths though. Good luck with it, and keep in touch.

If you want to experiment with the new LUA programming interface I'm adding to FSUIPC, let me know. I've got no documentation as yet but I can knock up some notes which would supplement the manuals on www.lua.org.

Regards

Pete