8 hours ago, kdfw__ said:

p3dv4 hf1.  

What version is this? Can you cross check the "My Documents\rxpGns.gau.log" file contains something like "oto not supported..." followed with your version?

11 hours ago, kdfw__ said:

3) swap to gns530 on the same aircraft works fine.

 

 

Is this a panel.cfg change,  or do you have both installed at the same time?

I have the GPS500 installed in the B60 Duke and it operates exactly like a GNS530 (minus the radios).

 

11 hours ago, RXP said:

What version is this? Can you cross check the "My Documents\rxpGns.gau.log" file contains something like "oto not supported..." followed with your version?

p3d is 4.0.28.21686

log file

17/09/25 04:25:41.864 03704 -    ] # rxpGNS2.dll version 2.3.3.0
17/09/25 04:25:41.869 03704 INFO ] 

8 hours ago, Bert Pieke said:

Is this a panel.cfg change,  or do you have both installed at the same time?

I have the GPS500 installed in the B60 Duke and it operates exactly like a GNS530 (minus the radios).

 

panel.cfg change.  

i guess when you operate the gps500, you'll not have the vloc button so using the gps/nav switch, right?  

Correct...

When I power up the Duke and move to the test page on the GPS500, the HSI needles

deflect when the NAV/GPS switch is in the GPS position.  When I move the switch to NAV, the needles

go back.

likewise, i see the gs/loc needles deflect in self test when the gps/nav=gps, no deflection when gps/nav=nav.  

49 minutes ago, kdfw__ said:

likewise, i see the gs/loc needles deflect in self test when the gps/nav=gps, no deflection when gps/nav=nav.  

In that case, the GPS should drive the autopilot in GPS mode.. I am puzzled that it would not work for you..

yes, weird. and 530 works just fine...

Unfortunately, I'm at a loss here as well for now. It there any difference whether or not you try with a DTO only, or a flight plan (for example an activated approach to an airport)?

On 9/26/2017 at 6:31 AM, RXP said:

Unfortunately, I'm at a loss here as well for now. It there any difference whether or not you try with a DTO only, or a flight plan (for example an activated approach to an airport)?

Jean-Luc, Bert,

reran the 'setup aircraft' from 'addons' pulldown on the tduke and for some reason the tduke is now able to fully function with the gps500.  i didn't save off the pre-edit rxp config file so not sure what exactly changed to make it work.  

so that's good news.

now, regarding the bezel at night--is there some thought as to adding a dark bezel .bmp for gauge placed in the vcockpit section?  please see https://www.avsim.com/forums/topic/520205-lpv-guidance-not-showing-using-gps500/?do=findComment&comment=3713683

 

 

This is great news indeed! 

As for the VC bezel lighting you have shown, we'll need to further investigate the root of the problem. If might be a gauge graphics handling issue, or just a byproduct of a particular VC. I won't promise this to be resolve quickly, but sure enough we'll get to the bottom of this in due time.

3 hours ago, RXP said:

This is great news indeed! 

As for the VC bezel lighting you have shown, we'll need to further investigate the root of the problem. If might be a gauge graphics handling issue, or just a byproduct of a particular VC. I won't promise this to be resolve quickly, but sure enough we'll get to the bottom of this in due time.

so here's the stock JF_C69 included with p3dv4 with gps added to the AP area:

rxp gns530 with vc lights ON, note the bezel, not dark but emissive.

next with the vc lights off, bezel lighting is the same, still emissive.

next is the stock gps, at night with vc lights on, bezel texture is the "_night.bmp" version, darker than regular:

no vc lights, the daylight emissive version is rendered:

so it seems bezel texture has to be selected based on the sim time to properly blend with the VC.

Ok I see this better now thank you for the detailed screenshots and info!

The issue there is to placard what is supposed to be a non-lighted bitmap (the bezel) onto a supposed lighted polygon (for the screen). You can see the stock GPS bezel is also wrongly depicted and should be dark when lights are off. However, like you're pointing out, we can try to 'trick' the system a little in changing the bitmap.

However, unlike with X-Plane which offers real-time Red/Green/Blue cockpit ambiant lighting which we use to render proper bezel in real-time, there is no such equivalent at all in FS (even P3D4) but a crude day/dusk-dawn/night value with no smooth transition.

FS general idea for the VC is to model a 3D bezel as non-emissive, the 3D screen as an emissive rectangle in the middle, and have a gauge render the screen pixels which are then textured over the emissive rectangle.

I'll see what the best we can do to mitigate this but I can't promise anything yet, because this is one strong limitation of the VC system.

16 hours ago, RXP said:

Ok I see this better now thank you for the detailed screenshots and info!

The issue there is to placard what is supposed to be a non-lighted bitmap (the bezel) onto a supposed lighted polygon (for the screen). You can see the stock GPS bezel is also wrongly depicted and should be dark when lights are off. However, like you're pointing out, we can try to 'trick' the system a little in changing the bitmap.

However, unlike with X-Plane which offers real-time Red/Green/Blue cockpit ambiant lighting which we use to render proper bezel in real-time, there is no such equivalent at all in FS (even P3D4) but a crude day/dusk-dawn/night value with no smooth transition.

FS general idea for the VC is to model a 3D bezel as non-emissive, the 3D screen as an emissive rectangle in the middle, and have a gauge render the screen pixels which are then textured over the emissive rectangle.

I'll see what the best we can do to mitigate this but I can't promise anything yet, because this is one strong limitation of the VC system.

Hi Jean-Luc,

thanks for looking into this matter. 

i think as a first step, would it not be quick and easy to provide a bezel that's black (or an user option to select choice of blackness)?  present bezel is something like rgb=59 59 59, a dark gray.  since the gns units are really black, going with 14,14,14 (highlighted areas) to 7,6,1 (quite black) would look fine during daylight and at night in the vc.  

and if you can trick the bezel to load appropriate bezel.bmp based on the crude fs time of day parameter, that would be excellent.  

Hi Patrick, you might want to review the notes I've just posted for the upcoming update:

PS: the trick to use 2 bitmaps, daylight and night, is for SDK gauges. Although our solution uses the SDK at its core, it barely uses the SDK for all things graphical. Otherwise, you'd be limited with 15bits bitmaps with colour banding, low-res graphics, no alpha blending etc... like any other gauge on the market.

Our technology renders 32 bits graphics with alpha (you can see the subtle blending of the GNS V2 integral lighting and the bezel), manages HIDPI images (the upcoming GTN 750 ships with bezel graphics at 2400x2300 which render as fast as standard SDK gauges at 100x100...). Moreover, our technology offers all these benefits on all simulators from FS9 to P3D4!

To this effect, the GNS V2 update offers per-instance adjustable 'brightness', which on this particular aircraft you're trying works well when set at 50%. Mind you, it won't adapt to ambient lighting yet, just because there is no standard way though the FS SDK, but we don't despair to find a way one day.